Hi, I have a strange behaviour with the Expect: 100 implementation as well. Remote server: Tomcat 8.0.28 Client: libcurl/7.54.0 OpenSSL/1.0.2k zlib/1.2.11 nghttp2/1.22.90 (Win32 / VS2015)
It seems as if the Tomcat server sends the 100 Continue faster than libcurl finishes with sending the Headers. Then libcurl hangs and does nothing more... From wireshark: Client -> Server: 3lP&5E_@xCN@NPPOST /diag/rest/v1/file HTTP/1.1 Host: valkyrie:8080 Accept: */* Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA Cookie: JSESSIONID=93687B4EF52F2B0F3FFBFEBEEFEBC335 Content-Length: 24563312 Expect: 100-continue Content-Type: multipart/form-data; boundary=------------------------7d495c8b81f24baf Server -> Client: (+1ms) P&53lEA@@CN@P&HTTP/1.1 100 Continue Client -> Server: (+4ms) 3lP&5Eh_@CN@P--------------------------7d495c8b81f24baf Content-Disposition: form-data; name="evaluation" 5138 --------------------------7d495c8b81f24baf Content-Disposition: form-data; name="evaluationType" HOLTER --------------------------7d495c8b81f24baf Content-Disposition: form-data; name="file"; filename="data" Server -> Client (+30ms) [ACK] Server -> Client (+20s) P&53lE@@6CN@P&dHTTP/1.1 400 Bad Request Server: Apache-Coyote/1.1 Cache-Control: no-cache Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 1033 Date: Wed, 26 Jul 2017 15:27:40 GMT Connection: close Is this a problem of Tomcat or of libcurl or of the underlying operating system? Thanks for help, David PS: I get this problem not very often... Am Mittwoch, 26. Juli 2017, 08:13:46 CEST schrieb Michael Felt: > On 7/6/2017 9:59 AM, Daniel Stenberg wrote: > > Hey, > > > > libcurl has hueristics to include the "Expect: 100-continue" header in > > several circumstances when doing POST and PUT requests. > > > > This header was designed to allow servers to reject a request before > > any data has been sent from the client, so that there would be less > > waste. It is especially useful with various kinds of HTTP auth > > mechanisms during which the 100 can save us from having to resend the > > entire (potenitally huge) POST body. > > > > In the real world however, there seems to be many more broken servers > > than working ones when it comes to supporting 100. If curl sees no > > response within 1000 milliseconds, it continues anyway and this pause > > is a very common reason for annoyance with curl. So many servers just > > don't see or care about Expect:. > > > > Then there's still the large group of servers that send a 100 response > > back immediately on all requests with Expect: even if the auth isn't > > fine, only to deny the request later anyway. Contrary to the intention > > of the header. > > > > The net result of all this is that switching off this Expect: header > > from libcurl requests is a very common thing. In many cases it removes > > a 1000ms pause from the request. In most other cases it makes no > > difference. In a rare few cases, it causes wasted bandwidth and > > additional roundtrips. > > > > The number of requests done "out there" today that unncessarily are > > waiting 1000 ms on each request is probably substantial. Switching the > > default could automatically make a huge amount of curl requests go > > faster in the future. > > > > Is it time to remove the automatic Expect: header use and only do it > > on demand? > > My gut response is: > a) leave the default behavior as it is. This is a well known behavior. > Straight "out of the box" configuration reversals "scare me" by > principal (as this one might be harmless, but hey - this is shooting > from the hip!). > b) add a message (perhaps to stderr as well as syslog) that a request > was made, but no response was made within 1000 msec, ideally in a way > that statistics could be collected (which servers never respond, e.g.) > > In short, since you had to ask - my gut says this is not a guaranteed > "100% harmless" change - and I would start with a message, or as a > configure option (maybe it is that already) and packagers can decide > and/or learn what works best. > > If putting it is configure is new - then you could put it in with the > default as is (e.g., true aka enabled), but add some info to README to > change the configure default to false (aka default request disabled). > And, this also gives you a moment to review the current documentation on > how to change the default in the config file (e.g., maybe what the > configure change does is change the result of a generated (default) > config file rather than actually changing code. > > Hope this helps! > > > We probably need to add a new option that turns on the current/old > > behavior if we do this. Alternatively we would just let the user set > > "Expect: 100-continue" as a custom header and detecting that, we would > > enable the internal logic for it, but that seems very error-prone and > > not very convenient. > > > > Applications that currently disable Expect: header use should of > > course not be affected by this sort of change. They would just disable > > it extra much! =) > > > > Thoughts? > > ------------------------------------------------------------------- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
