curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Time to disable "Expect: 100-continue" by default?

From: Stefan Eissing <stefan.eissing_at_greenbytes.de>
Date: Thu, 6 Jul 2017 12:13:50 +0200

> Am 06.07.2017 um 11:48 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> 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
Received on 2017-07-06