'Expect' header gives HTTP error 417

[anonymous]

Respin of http://trac.lighttpd.net/trac/ticket/658 for lighttpd-1.4.13.

It is not possible to post a form to lighty that contains the 'Expect' header. Any such request is met with a 417 (Bad Expectation).

It badly affects Curl.

[darix]

fixed in 1.5. we wont fix this for 1.4

[origo]

Replying to darix:

fixed in 1.5. we wont fix this for 1.4

How nice of you. This means I have to upgrade to a non-stable version to be able to use several mobile handsets as clients (SonyEricssonW220i is only one that sends an Expect header). You have effectively killed mobile applications with Lighty 1.4.

[darix]

Replying to origo:

Replying to darix:

fixed in 1.5. we wont fix this for 1.4

How nice of you. This means I have to upgrade to a non-stable version to be able to use several mobile handsets as clients (SonyEricssonW220i is only one that sends an Expect header). You have effectively killed mobile applications with Lighty 1.4.

might be. but the problem is the changes to properly support this are to big to do them on a maintenance branch. for such big changes we stick to 1.5. last but not least 1.5 runs pretty stable already

[origo]

No worries. I put a reverse-proxy Apache 2.2 in front of Lighty that disables the Expect-header. Feel free to contact me for details if anyone else needs this.

[anonymous]

Origo: I don't know if you're going to get an email for this or not, but if you do, please contacts me at mbulman-at-webmail.us. I would love to hear your solution.

[anonymous]

Hey Origo, can u contact me at cyberline dot t4e dot fm for a solution with the reverse proxy ? thanx

[origo]

How do you make an email addres out of "cyberline dot t4e dot fm" ?(sorry for spamming the comments, but the guy needed help)

[anonymous]

The original post mentioned curl. You can use the -H option of curl to turn off the Expect header. I used the following: -H 'Expect: '

[anonymous]

This also affects the Wordpress 2.5 which has a dependence on lighttpd 1.5 for its new image uploader (SWFupload)... any chance of a backporting the fix for 1.4.19 as there is no release date for 1.5

Thanks

[anonymous]

Tried using 1.5, as it is now its so broken the only thing that will display correctly is sea monkey. This is a joke...

[hoffie]

Guys, please calm down. Please keep in mind that lighttpd is an opensource project and that nobody pays anybody to work on the code. All developers do it because they like to do so (sometimes more, sometimes less, I guess).

Comments like "How nice of you" or "This is a joke" certainly do not motivate developers to invest more time. Last but not least, not fixing the problem in 1.4 was even explained -- apparently a very severe change would be needed, and it is unacceptable to do so in a maintainance-only branch.

You might argue that 1.5 has been waiting for a release already for a long time, but well, recall again, what I mentioned at the beginning of this post. Also, to get things moving faster again, testing is needed. Testing is something you can do. If you are not willing to, we do not have a problem with you using a different web server as well.

Just on a sidenote, I'm using 1.5 on multiple servers without any problems, and I doubt that any rendering-related problems have something to do with the web server (version).

[Olaf van der Spek]

Replying to darix:

might be. but the problem is the changes to properly support this are to big to do them on a maintenance branch. for such big changes we stick to 1.5. last but not least 1.5 runs pretty stable already

When can 1.5 be expected? ;) If the change is too big to do in a 1.4 release, you could rename 1.5 to 1.6, do the changes in 1.4 and release it as 1.5.

1.5 isn't a solution until it's released.

[anonymous]

Rather than implementing correct "100 continue" behaviour (a big fix, you say), or returning "417" (which is wrong), why not simply ignore the header? HTTP 1.1 clients should still work, since they're supposed to go ahead and send the body anyway if they've never seen a "100 Continue" response.

[anonymous]

why not simply ignore the header?

They'd rather whine about not being paid than implement a trivial fix. This is why it's hard to take a lot of open source seriously: they won't fix the simplest of bugs and use the blanket "we're doing this for free!" excuse, which is just declaring that they couldn't care less if their software works for anyone but them, and that we're the fools for becoming dependent on it.

You can work around this in curl by adding -H "Accept:" to suppress the header, or you can comment out the header code in the server and it works fine (request.c, search for "100-continue" to find the block to comment out).

[stbuehler]

1. not a bug - see http://tools.ietf.org/html/rfc2616#section-14.20
2. if you think it is a trivial fix, then please provide a patch. and till that, just stfu.
3. fix your clients

[anonymous]

Man I love all these comments from people complaining that other people aren't fixing the supposedly extremely simple bugs. It's an open source project. If the fix is so simple, do it yourself and donate.

Welcome to the internet.

[anonymous]

Fix for PHP skripts that are using curl:

<?php
$ch = curl_init();
curl_setopt($ch,CURLOPT_HTTPHEADER,array("Expect:"));
//Other setopt, execute etc...
?>

[Chris]

Are there known bad side effects to commenting out the code mentioned above? Can the person above who said that provide a more detail about what to comment out. This problem apparently also prevents uploads from some Flash uploaders too. Since I'm using a Flash uploader on my site I'd either have to throw out Lighttpd and use apache again or try using 1.5 or maybe most reasonable of all, just comment out the code. Can a developer comment on whether that is likely to cause other issues and hence it's not recommended? Is 1.5 being used in production servers already and a better choice than hacking 1.4.19?