httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: bug sending 100 all the time
Date Fri, 02 Oct 1998 01:28:19 GMT
>1. Every HTTP server SHOULD send 100 continue when it gets a request
>with an entity, if it's prepared to read the request.
>2. A HTTP client sending an entity should send the headers, then it SHOULD
>wait five seconds or so for a 100 response, before going ahead and sending
>the entity.

Dude, #1 was "unless it has already determined the final response"
and #2 was changed in 1996 (nobody liked it, but it was needed for
discussion).  I think all the short-term useless standards stuff in
your noggin got flushed last year to make room for all that useless
Stanford stuff they force undergrads to learn. ;-)

>Your explanation of why 100 Continue exists is also wrong, at least to my
>recollection. It wasn't to save the *client* bytes, but to save the server
>- if it didn't want an entity, it wasn't supposed to get one, by sending a
>4xx or 5xx response directly. Since the client is supposed to be waiting
>for a 100, the server won't get swamped with data it doesn't want. So in
>the case that the server does want data (should_client_block is the API
>call that tells Apache this), we always want to send 100. Which we do.

Actually, it was originally there to solve the lingering close/reset
problem of the server's response getting lost if the client kept sending
data.  Needless to say, we fixed that differently, so the only reason left
was to save the client from uploading a 4MB file when there is a high
probability of a 401 or 302 response to the initial request.

That was RFC 2068.  The current rev-05 changes it again and says to
only send it when "Expect: 100-continue" (or something similar) is in
the request.  It sure is nice of them to introduce a conflicting
requirement to the protocol without changing the HTTP version number.
ain't it?


View raw message