Which browsers send the expect: 100-continue header?

Question

The HTTP/1.1 spec allows for clients to send an Expect: 100-continue header for large request payloads (8.2.3 Use of the 100 (Continue) Status - Hypertext Transfer Protocol -- HTTP/1.1 - RFC2616).

This will pause the request after the headers have been sent and allow the server to reject it based on those headers.

If those headers did not indicate a bad request (e.g. a too large Content-Length), then it responds with a 100 Continue status line, allowing the client to proceed. At this point the client sends the request body.

Which browsers actually support this, and under which conditions will they send the expect header?

Outguess

Please explain why you want to know what browsers implement this behavior. If you want to test stuff, there are other tools than browsers. – Hinson

@Hinson Being able to rely on it for pre-validating huge uploads would be nice. But I'm mostly just curious. – Outguess

I would like to know as well. Our load test software (MS Visual Studio) sends the "Expect:100-continue" header and seems to cause problems with our load balancer. When I disable it from using that header, it works fine. If no browser is sending the "Expect:100-continue" header, then I see no reason to worry about the issues that our load balancer has with the 100-continue header and can continue to disable our load tests from sending that header. – Indigent

Answer 1

I know that curl does this for every post request. Was just running over that some time ago.

I also tested that in conjunction with PHP in "How can I stop cURL from using 100 Continue?".

Olav

What about desktop browsers? Is there any way to support a 100 Continue with a normal POST request? If so, in which browsers? – Frow

Well technically any HTTP/1.1 client can make use of that. In the desktop world that can be for example WebDAV clients, AJAX requests from within browsers, request resulting from browser plugins. I know you ask for WWW Browsers specifically, but I would assume you are asking from a servers perspective and unless you do not want to support HTTP/1.1, you do not need to ask which Browser - it's part of the specs. Support it or tell the client to that the HTTP/1.1 version is not supported: 10.5.4 503 Service Unavailable. – Olav

Correction: The link in my comment was wrong. This was a copy/paste error I noticed too late. The link I originally wanted to place however was wrong too. A more correct response might be 10.4.18 417 Expectation Failed if you have a request with expect and you do not want to deal with it on your service implementation. I know this still does not answer the question which WWW browsers in the wild do perform such requests bare on their own. – Olav

I went through the source codes of Chromium, WebKit and Firefox yesterday, they all have treatment which relates to Expect: 100 Continue but none of them seems to support it. They each have bugs that mention this lack of support but it's not documented any-where code.google.com/p/chromium/issues/… bugzilla.mozilla.org/show_bug.cgi?id=803673 – Frow

For clients lack-of-support is relative. Clients can implement this at free will, origin servers can't. From a servers perspective you need to decide whether or not you want to support it. Also clients "SHOULD NOT wait for an indefinite period before sending the payload body" (6.1.2.1.). It remains fishy in the specs so it's the specs fault here to allow everything that goes. – Olav

Maybe I should mention that the context is #16168435 Specifically igorw 's solution at the end of the answer body – Frow