27

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?

Community
  • 1
  • 1
igorw
  • 27,759
  • 5
  • 78
  • 90
  • Please explain why you want to know what browsers implement this behavior. If you want to test stuff, there are other tools than browsers. – CodeCaster May 03 '13 at 11:49
  • 5
    @CodeCaster Being able to rely on it for pre-validating huge uploads would be nice. But I'm mostly just curious. – igorw May 13 '13 at 01:02
  • 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. – Makotosan Nov 07 '13 at 18:02

1 Answers1

5

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?".

Community
  • 1
  • 1
hakre
  • 193,403
  • 52
  • 435
  • 836
  • What about desktop browsers? Is there any way to support a 100 Continue with a normal POST request? If so, in which browsers? – Benjamin Gruenbaum May 03 '13 at 03:56
  • 1
    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](http://tools.ietf.org/html/rfc2616#section-10.1.2). – hakre May 03 '13 at 09:55
  • ***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](http://tools.ietf.org/html/rfc2616#section-10.4.18) 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. – hakre May 03 '13 at 12:32
  • 4
    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 https://code.google.com/p/chromium/issues/detail?id=174906&can=1&q=%22Expect:%20100- https://bugzilla.mozilla.org/show_bug.cgi?id=803673 – Benjamin Gruenbaum May 03 '13 at 12:42
  • 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. – hakre May 03 '13 at 13:03
  • 1
    Maybe I should mention that the context is http://stackoverflow.com/questions/16167935/break-http-file-uploading-from-server-side-by-php-or-apache/16349882#16349882 Specifically igorw 's solution at the end of the answer body – Benjamin Gruenbaum May 03 '13 at 13:04