Re: 100 Continue

> Questions about HTTP 1.1's new status code of 100 (Continue).
> 
> 1.  How does this status code make HTTP more efficient?  The
>     spec states that the client will know that its request (so far)
>     hasn't been rejected and it is okay to continue the request.
>     I'm not sure how this status code is more efficient than 
>     the client finishing up its request and receiving an error
>     code.  Can someone think of an example that explains this
>     more?  I'm thinking that 1 or 2 packets are saved by doing this.
>     Or are there greater savings?  (Does anyone have research
>     findings they would like to share?)

It doesn't exist for the sake of efficiency. It exists because if the
server desires to signal an error before the request body is received
(e.g., 401 Unauthorized) and it then closes the connection while the 
client is still sending data, the TCP-layer of the connection will 
send a RST packet to the client which will most likely result in the
server's response being deleted from the client's TCP queue before
the client gets a chance to read it, which in turn results in the
client attempting to repeat the same request and getting the same error ...

The 100 code allows for a two-phase exchange.  It also allows us to
introduce the concept of an informational response, which is something
people have been thinking about for years.
 
> 2.  It appears that multiple response codes are possible...
>     I'm not sure if I am interpreting this correctly... is it like this?
> 
> Client:
> 
> GET / HTTP/1.1
> [headers go here]
> CRLF
> entity-body
> 
> Server:
> HTTP/1.1 100 Continue    [midway between the client's request]
> HTTP/1.1 200 OK          [when the client is finished requesting]
> [headers go here]
> CRLF
> entity-body
> 
> Is this the correct interpretation?  

Almost.  It is

Server:
    HTTP/1.1 100 Continue    [midway between the client's request]
    [headers go here]
    CRLF
    HTTP/1.1 200 OK          [when the client is finished requesting]
    [headers go here]
    CRLF
    entity-body

assuming it is successful.  Note that 1xx responses cannot be sent or
forwarded to an HTTP/1.0 client.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 8 October 1996 21:05:06 UTC