Re: bug sending 100 all the time

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

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

....Roy

Re: bug sending 100 all the time

[Jim Gettys <jg...@pa.dec.com>]

> Sender: new-httpd-owner@apache.org
> From: Alexei Kosut <ak...@leland.Stanford.EDU>
> Date: Thu, 1 Oct 1998 19:01:13 -0700 (PDT)
> To: new-httpd@apache.org
> Subject: Re: bug sending 100 all the time
> -----
> On Thu, 1 Oct 1998, Roy T. Fielding wrote:

Material elided.

> 
> Yes :) Anyway, as I said, I was just commenting on why the code was like
> it is. I haven't followed the HTTP standards in about two years, so I
> plead ignorance on any changes since RFC 2068. My point was that that
> version of HTTP/1.1 had a bunch of nasty SHOULDs that made it so that an
> HTTP/1.1 request w/ entity would cause a five-second lag unless the server
> sent 100 Continue with *every* response, regardless of what the final
> response code would be.
> 
> I'm glad it got changed.
> 

We aim to please :-).

The point of the IETF process is to get such botches found and fixed.

RFC 2068 was rushed, as far as I was concerned; I'm much, much happier
with the current state of the document (in IETF last call right now).

Implementers will particularly like the index...
				- Jim

Re: bug sending 100 all the time

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Thu, 1 Oct 1998, Roy T. Fielding wrote:

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

Right. Sorry; I hadn't thought that part of your original message through
completely yet.

> 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. ;-)

Yes :) Anyway, as I said, I was just commenting on why the code was like
it is. I haven't followed the HTTP standards in about two years, so I
plead ignorance on any changes since RFC 2068. My point was that that
version of HTTP/1.1 had a bunch of nasty SHOULDs that made it so that an
HTTP/1.1 request w/ entity would cause a five-second lag unless the server
sent 100 Continue with *every* response, regardless of what the final
response code would be.

I'm glad it got changed.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *