Feature #1017

'Expect' header gives HTTP error 417

Added by Anonymous over 7 years ago. Updated about 3 years ago.

Status:FixedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:core
Target version:-
Missing in 1.5.x:No

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.

lighttpd-1.4-expectation-failed.diff Magnifier (1.15 KB) peto, 2009-02-01 01:21

Associated revisions

Revision 2385
Added by stbuehler over 5 years ago

Add option to ignore the "Expect: 100-continue" header instead of returning 417 Expectation failed (closes #1017)

History

#1 Updated by darix over 7 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

fixed in 1.5.
we wont fix this for 1.4

#2 Updated by origo over 7 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.

#3 Updated by darix over 7 years ago

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

#4 Updated by origo over 7 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.

#5 Updated by Anonymous about 7 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.

#6 Updated by Anonymous almost 7 years ago

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

#7 Updated by origo almost 7 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)

#8 Updated by Anonymous over 6 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: '

#9 Updated by Anonymous over 6 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

#10 Updated by Anonymous over 6 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...

#11 Updated by hoffie over 6 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).

#12 Updated by admin over 6 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.

#13 Updated by Anonymous over 6 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.

#14 Updated by Anonymous over 6 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).

#15 Updated by stbuehler over 6 years ago

  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

#16 Updated by Anonymous about 6 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.

#17 Updated by Anonymous about 6 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...
?>

#18 Updated by Anonymous about 6 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

#19 Updated by AYakeley over 5 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."

#20 Updated by stbuehler over 5 years ago

  • Patch available set to No

".. or respond with a final status code", which is exactly what we do.

#21 Updated by peto over 5 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.

#23 Updated by stbuehler over 5 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".

#24 Updated by peto over 5 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.

#25 Updated by icy over 5 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.

#26 Updated by stbuehler over 5 years ago

  • Status changed from Reopened to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2385.

#27 Updated by JustinK101 over 3 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

#28 Updated by nitrox over 3 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!

#29 Updated by Nksswiss about 3 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

#30 Updated by icy about 3 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.

#31 Updated by stbuehler about 3 years ago

  • Status changed from Reopened to Fixed

Also available in: Atom