Re: 100 Continue and Expects

Greg Wilkins wrote:
> thanks for that info.  I had not realized that the client had
> not choice but to not reuse the connection if a non-100 response
> is received.

I believe it's ok to reuse the connection if it posts a request body
matching the headers.  However:

> Then perhaps the bis spec can enhanced to make this point clearer.

I found this part of RFC2616 a little confusing:

    8.2.2 Monitoring Connections for Error Status Messages

       An HTTP/1.1 (or later) client sending a message-body SHOULD
       monitor the network connection for an error status while it is
       transmitting the request. If the client sees an error status,
       it SHOULD immediately cease transmitting the body. If the body
       is being sent using a "chunked" encoding (section 3.6), a zero
       length chunk and empty trailer MAY be used to prematurely mark
       the end of the message.  If the body was preceded by a
       Content-Length header, the client MUST close the connection.

As far I know, the client does not have to close the connection, if
it continues to transmit the rest of the body.

And if it does close, of course it shouldn't do so until it's seen the
whole response, not just the "error status".

Moreover, I wasn't sure what _exactly_ counts as an "error status", as
it's not a defined term, and 3xx (not an error) would seem to need the
same behaviour.  Or even 2xx, if the request body isn't relevant.
(Although I really like the idea of simultaneously streaming
request and response bodies).

> It might also be good to suggest that servers send Connection: close
> with non 100 responses if expect 100 is received.  This would
> make clients that don't know they should close, do the close.

I don't think it's necessary for them to close, despite the MUST above
;-) In other words, I parse the above RFC2616 extract with the MUST
clause conditional on the client performing the SHOULD and ceasing to
transmit the body - if it hasn't already finished that.

Actually I go a bit further:

With certain types (Microsoft) of authentication, the client must not
close the connection...

Here's a proposed alternative text.  It could be tidied a bit:

    8.2.2 Monitoring Connections and Aborting Request Bodies

       An HTTP/1.1 (or later) client sending a message-body SHOULD
       monitor the network connection for a response while it is
       transmitting the request.  If the client sees a 3xx, 4xx or 5xx
       status, it SHOULD immediately cease transmitting the body (by
       which we also mean not starting to transmit if it has not
       started), although it MAY continue transmitting the body if
       there is not much remaining to transmit, the latter being an
       implementation-defined heuristic.  All references to ceasing to
       transmit the body shall

       The client SHOULD also cease transmitting the body, subject to
       the above option to continue transmitting, if it sees a 2xx
       status which is not preceded by 100 (Continue) after it had
       sent the Expect request header field with the "100-continue"
       expectation.  This allows a server to indicate that it is still
       consuming the request body while it sends the response, or to
       indicate that it does not require the request body.

       When ceasing to transmit the body, if the body is being sent
       using a "chunked" encoding (section 3.6), a zero length chunk
       and empty trailer MAY be used to prematurely mark the end of
       the message, and connection reuse is possible.

       When ceasing to transmit a body which was preceded by a
       Content-Length header, the client SHOULD halt transmission and
       wait until it has received the response, and it MUST close the
       connection without sending another request.  If the client
       requires the whole response, it MUST NOT signal end of
       transmission prior to receiving the whole response by
       "half-closing" the connection, in the sense described as
       simplex close in [RFC793] section 3.5, as that typically causes
       the server to cease transmitting the response.

An idea: When aborting with a zero length trunk, could we append an
"aborted" chunk-extension, to indicate clearly that it was truncated,
not ended cleanly?

-- Jamie

Received on Sunday, 28 March 2010 14:20:29 UTC