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
