Hey,

libcurl has hueristics to include the "Expect: 100-continue" header in several circumstances when doing POST and PUT requests.

This header was designed to allow servers to reject a request before any data has been sent from the client, so that there would be less waste. It is especially useful with various kinds of HTTP auth mechanisms during which the 100 can save us from having to resend the entire (potenitally huge) POST body.

In the real world however, there seems to be many more broken servers than working ones when it comes to supporting 100. If curl sees no response within 1000 milliseconds, it continues anyway and this pause is a very common reason for annoyance with curl. So many servers just don't see or care about Expect:.

Then there's still the large group of servers that send a 100 response back immediately on all requests with Expect: even if the auth isn't fine, only to deny the request later anyway. Contrary to the intention of the header.

The net result of all this is that switching off this Expect: header from libcurl requests is a very common thing. In many cases it removes a 1000ms pause from the request. In most other cases it makes no difference. In a rare few cases, it causes wasted bandwidth and additional roundtrips.

The number of requests done "out there" today that unncessarily are waiting 1000 ms on each request is probably substantial. Switching the default could automatically make a huge amount of curl requests go faster in the future.

Is it time to remove the automatic Expect: header use and only do it on demand?

We probably need to add a new option that turns on the current/old behavior if we do this. Alternatively we would just let the user set "Expect: 100-continue" as a custom header and detecting that, we would enable the internal logic for it, but that seems very error-prone and not very convenient.

Applications that currently disable Expect: header use should of course not be affected by this sort of change. They would just disable it extra much! =)

Thoughts?

--

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

Reply via email to