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.No comments