> Am 06.07.2017 um 11:48 schrieb Daniel Stenberg <[email protected]>: > > On Thu, 6 Jul 2017, Stefan Eissing wrote: > >> 2) If the client is unable to resend the data, its request would fail >> otherwise. > >> For 2) alone the servers really need to implement Expect: headers correctly. >> And clients should expect a correct implementation. > > Is there any data that suggests that HTTP/2 servers support 100-continue > better than HTTP/1 servers? > > I'll admit that my suggestion here is entirely based on my gut feeling after > discussions with people over the years, and not on any real numbers as I > don't have any numbers, but I've also heard how the 100 problem exists partly > because that's a HTTP layer response while the people writing the web app > logic often work on a layer on top of that and aren't in control of what the > server responds that early. I don't think HTTP/2 changes that argument.
Well, in the little server I work for, the Expect/100-continue handling is done at the protocol handling level, not the "application", e.g. a CGI/php whatever application. But I have seen implementations which think it's the applications responsibility (or just did not care). The Java Servlets spec did it make impossible for an app to answer such a header... So, yes, it's bad, but I still believe in the h2 implementations... ;-) >> As long as the request is repeatable, send the data right away. > > Right. So you're talking about tweaking/improving the hueristics. If curl > thinks it can rewind, skip the header. > > That might be a better default route, yes... > >> But does libcurl right now know when request data is repeatable or not? >> Here, my experience is limited. CURLOPT_READDATA does not specify, right? >> So, for libcurl users, the proposed change could cause breakage. > > If you pass data to libcurl with a callback you also need to set the > CURLOPT_SEEKFUNCTION callback so that libcurl can ask for the data to get > rewound if it needs to send it again. Without the seekfunction there can be > no rewinding. Of course the seek function *can* also return an error so we > can't fully know before-hand if resending works even then. > > Already today, current servers with broken 100 support and HTTP request > bodies pretty much already require rewinding support for HTTP request using > authencation etc. Thanks for the hint about SEEK. That seems a good enough indication that a libcurl user is willing to rewind the data and make skipping Expect like a good choice. -Stefan > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > 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
