wiredfool

Recently we shifted the core of the webapp at work to run on lighttpd/php5 connected by fcgi from the standard apache1.3/mod_php4. There have been a couple of cases where people using the POST api methods have consistently gotten a connection closed error with lighttpd version where everything worked properly on apache.

This is the post:

POST /api.php HTTP/1.1
Content-Type: text/xml
Host: www.example.com:443
Content-Length: 19742
Expect: 100-continue
Connection: Keep-Alive
X-Forwarded-For: 10.0.0.0

<TransactionRequest>
...

and this is the response from lighttpd:

HTTP/1.1 417 Expectation Failed
Connection: close
Content-Length: 0
Date: Thu, 30 Oct 2008 19:35:29 GMT
Server: lighttpd/1.4.13

and the response from Apache:

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Date: Thu, 30 Oct 2008 19:37:26 GMT
Server: Apache/1.3.34
X-Powered-By: PHP/4.4.4-8+etch6
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml

<?xml version="1.0" encoding="iso-8859-1"?>
...

To make matters worse, it appears that pound, our front end load balancer, doesn’t log the error, but it does show up in the lighttpd logs as expected.

So, what’s the problem? It’s the expect header. Lighttpd doesn’t support it, and sends back a 417 Expectation failed error if that header is included. It’s a known WontFix bug for the 1.4 series, and the 1.5 series has been expected for a long while now.

The thing is, there are a lot of command line http clients or libraries out there that send this header, and it’s distressing that lighttpd simply can’t work with them.

And then, what’s the fix?

I’m afraid that it’s goign to be to route around lighttpd for now, either by replacing with apache2 or ngnix. There’s an outside possibility that I’ll be able to filter the header on the load balancer, but that’s not looking likely right now.