Was with Daniel von Twitter, but the discussion is better placed here.

In my mind, the 100-continue serves 2 purposes:

1) it protects the HTTP/1.1 connection. E.g. the server, sending a 4xx response, either has to read all the bytes from the client or close the connection early. Which has also other disadvantages.

2) it protects the client so that there is reasonable chance that the request succeeds. If the client is unable to resend the data, its request would fail otherwise.

This was a good protocol invention in HTTP/1.1, but as you know, there is stupid server software out there that does not care about this. Re the current workaround with 1sec timeout.

I argue that in HTTP/2, the part 2) still applies, while 1) is is addresses by stream close/RST. For 2) alone the servers really need to implement Expect: headers correctly. And clients should expect a correct implementation.

So. What about curl? As long as the request is repeatable, send the data right away. 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.

Cheers,

Stefan
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-07-06