Lighttpd

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.

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

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.

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.

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

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

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: '

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

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

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).

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.

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.

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).

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.
3. fix your clients

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.

Fix for PHP skripts that are using curl:

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

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?

-- Chris

417 is higher level: if you send 417, then that means you don't know about the expectation at all, in which case the language of that expectation (such as "... or respond with a final status code") is irrelevant; you're saying you don't know about it to begin with. If you're giving a response within the rules of the expectation, that means you support the expectation, and 417 is no longer a valid response. (That's clearly not what "or respond with a final status code" is for.)

In any case, 100-continue does not appear optional; it's not an expectation-extension. 8.2.3 doesn't define this as optional behavior, or mention any kind of fallback requirements for clients (other than that old servers may ignore Expect entirely, which lighttpd isn't doing). There's no mechanism for clients to automatically determine that 100-continue is unsupported and retry without it: 417 doesn't encode which expectation failed.

An easy partial fix for 1.4 is to ignore the Expect header entirely. It still violates the current revision of the spec, but in a well-documented way: the spec clearly advises clients about handling this case, since that's what older servers did. The current behavior does nothing but break compatibility with clients.

Patch for 1.4 attached--not with much hope of it being applied, but to help out the many people being bit by this. Tested successfully with curl.

rfc 2616 14.20:

A server that does not understand or is unable to comply with any of
the expectation values in the Expect field of a request MUST respond
with appropriate error status.

We are unable to send 100-continue, so...

And:
rfc 2616 8.2.3:

Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100-
continue" without receiving either a 417 (Expectation Failed) status
or a 100 (Continue) status.

This clearly indicates that a http/1.1 client must be able to deal with 417 for a request with "Expect: 100-continue".

I don't agree (that line means "you might receive no response at all", reading further into it is contrived: you can receive any 4xx/5xx code there, which that line seems ignorant of), but whatever. The patch is available for those who want real-world compatibility.

Did you look into why it is failing? See what status is returned by lighty. Simplest way would be to look at the accesslog.
Chrome can also show you in the developer tab what requests Flash is issueing I think.
The patch is not non-SSL specific so that's not it. Something else must be the issue for you.
Maybe Flash does not like your self signed cert, I'm not familiar with Flash in that regard.