Goliath cannot handle "Expect: 100-Continue"
maxlinc opened this issue · 2 comments
This was discussed on the mailing list but I didn't see an issue and it appears unresolved.
The proposed workaround doesn't work. It appeared to at first, but only because curl sends the body after a timeout.
Curl will always wait for 100-continue. To remove it use: -H'Expect:'
when sending the request.
That said, the response you linked to also looks correct. See RFC: http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code.
Thanks for the quick reply. I've tested with multiple different clients (libcurl based, Apache HTTP, .NET, etc). libcurl is actually the most forgiving of broken 100-continue support, and only results in a 1s delay before sending the body. Many other clients fail after a timeout, without ever sending the request body.
I think that curl can show there is still an issue, though. I think you're right it is a valid response, but it's coming too late. Try changing the response from a 100 Continue
to a 417 Expectation Failed
. That should cause curl to abort the request, but curl it doesn't. I compared the Goliath behavior with that of this Unicorn/Sinatra solution. I found that the Unicorn/Sinatra solution worked as I expected for either 100 or 417, but Goliath didn't. Implementing it in on_headers doesn't work for the 417. I also tried the same middleware from the Unicorn/Sinatra solution, and found that Goliath hung on the second request.
I commented on the gist to keep the code samples in one spot, and to link the mailing list/gist to this issue.
Final note: Unfortunately properly implementing 100 Continue support is probably non-trivial. I found the Use of the 100 (Continue) Status section of the RFC 2616, which includes 5 requirements for HTTP 1.1 origin servers, and 4 requirements for HTTP 1.1 proxies.