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