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.

> 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.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html