Feature #1017
closed'Expect' header gives HTTP error 417
Description
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.
Files
Updated by darix over 17 years ago
- Status changed from New to Fixed
- Resolution set to fixed
fixed in 1.5.
we wont fix this for 1.4
Updated by origo over 17 years ago
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.
Updated by darix over 17 years ago
Replying to origo:
Replying to darix:
fixed in 1.5.
we wont fix this for 1.4How 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
Updated by origo over 17 years ago
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.
Updated by Anonymous about 17 years ago
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.
Updated by Anonymous almost 17 years ago
Hey Origo, can u contact me at cyberline dot t4e dot fm for a solution with the reverse proxy ? thanx
Updated by origo almost 17 years ago
How do you make an email addres out of "cyberline dot t4e dot fm" ?(sorry for spamming the comments, but the guy needed help)
Updated by Anonymous over 16 years ago
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: '
Updated by Anonymous over 16 years ago
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
Updated by Anonymous over 16 years ago
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...
Updated by hoffie over 16 years ago
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).
Updated by admin over 16 years ago
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.
Updated by Anonymous over 16 years ago
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.
Updated by Anonymous over 16 years ago
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).
Updated by stbuehler over 16 years ago
- not a bug - see http://tools.ietf.org/html/rfc2616#section-14.20
- if you think it is a trivial fix, then please provide a patch.
- fix your clients
Updated by Anonymous over 16 years ago
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.
Updated by Anonymous over 16 years ago
Fix for PHP skripts that are using curl:
<?php $ch = curl_init(); curl_setopt($ch,CURLOPT_HTTPHEADER,array("Expect:")); //Other setopt, execute etc... ?>
Updated by Anonymous about 16 years ago
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
Updated by AYakeley over 15 years ago
- Assignee set to stbuehler
stbuehler: this is not correct. As you point out, the server must return 417 to expectations it doesn't recognise. However, a compliant HTTP server must recognise "100-continue". From http://tools.ietf.org/html/rfc2616#section-8.2.3:
"Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code."
Updated by stbuehler over 15 years ago
- Patch available set to No
".. or respond with a final status code", which is exactly what we do.
Updated by peto over 15 years ago
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.
Updated by peto over 15 years ago
Updated by stbuehler over 15 years ago
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".
Updated by peto over 15 years ago
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.
Updated by icy over 15 years ago
- Status changed from Fixed to Reopened
- Target version changed from 1.4.13 to 1.4.21
Due to the RFC explicitly mentioning that ignoring it is valid (deprecated but valid) and a lot of clients sending it (and probably being capable of handling the lack of support for it from the webserver), I tend to agree that ignoring it would be a better real-world solution.
Maybe we could add a config option like "server.ignore-100-continue" which would be enabled by default and let the users decide if they really want that.
That would seem like a compromise everyone could live with.
Updated by stbuehler over 15 years ago
- Status changed from Reopened to Fixed
- % Done changed from 0 to 100
Applied in changeset r2385.
Updated by JustinK101 over 13 years ago
- Status changed from Fixed to Reopened
- Assignee changed from stbuehler to icy
- Target version changed from 1.4.21 to 1.4.x
- % Done changed from 100 to 0
What the deal on this? Over two years later, and still a problem. I am running:
lighttpd/1.4.28 (ssl) - a light and fast webserver
Build-Date: Aug 22 2010 21:27:23
Trying to build a RESTFul API, but when clients in curl use: curl http://api.mydomain.com/action -F "key=value"
Getting back 417 - Expectation Failed
Can you please implement a fix, perhaps the server.ignore-100-continue
Updated by nitrox over 13 years ago
- Status changed from Reopened to Fixed
- Assignee deleted (
icy) - Target version deleted (
1.4.x) - Missing in 1.5.x set to No
server.reject-expect-100-with-417 - Please read more carefully next time!
Updated by Nksswiss over 13 years ago
- Status changed from Fixed to Reopened
server.reject-expect-100-with-417 works nicely with SWFUploader for me - but .. as i turn on SSL (self-signed) - I/O Error is coming up ..
So again:
http://myserver.com/uploadtest/ .. -> Upload works fine
https://myserver.com/uploadtest/ .. -> Broken ..
so i guess - maybe the "patch" (server.reject-expect-100-with-417) is not implemented in SSL Mode ?
As fileupload is an important part of my webapp (crm system) - i need to have functional swfupload with https ..
already thought about switching back to apache2 (laaame .. ) - but as i found the "server.reject-expect-100-with-417" patch -
i thoughts its solved .. so i would be really happy if you could help
Thanks for help / feedback
Updated by icy over 13 years ago
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.
Also available in: Atom