Re: Pipelining and Expect: 100-continue interaction

I think I found some of what I was looking for in section 8.2.2 of RFC 2616:

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.
So, in case 2 below, if the Content-Length was sent, then the client must 
close the connection upon receiving the 417 error from the server. If using 
"chunked" encoding then at most a zero length chunk will be sent, which 
will be discarded.

and from Section 8.1.2.2 of RFC 2616
A client that supports persistent connections MAY "pipeline" its requests 
(i.e., send multiple requests without
waiting for each response).
Since the "request" is complete until the entity body is send (or a zero 
length chunk) then no other requests can be pipelined.

Thanks,
Marc

At 11:36 AM 4/22/2005, Marc Schneider wrote:
> From section 8.2.3 of RFC 2616:
>
>If it [the origin server] responds with a final status code, it MAY close the
>transport connection or it MAY continue to read and discard the rest of 
>the request. It MUST NOT perform
>the requested method if it returns a final status code.
>
>If the server sends an error response (without 100 Continue), then there 
>are two cases:
>1) The client started sending the entity body, or
>2) The client didn't send the entity body and won't send an entity body.
>
>In case 1, the origin server can continue to read and discard the rest of 
>the request, the server doesn't need to close the transport connection and 
>once the entity body has been discard the origin server can process other 
>requests on the connection.
>
>In case 2, the origin server will keep the connection open and will 
>continue to process requests on the connection. The client may then send 
>another request.
>
>How would the server know when to discard the data or not to discard the 
>data? I could imagine that a server would attempt to parse the data as if 
>it was an HTTP request start line and discard the data if it doesn't parse 
>correctly. If it does parse correctly, the server would process it as a 
>new request. In this case, pipelining of request would be possible.
>
>Is there something specific in the RFC that you could point to that says 
>that this is not legal?
>
>Thanks,
>Marc
>
>At 11:03 AM 4/22/2005, Jamie Lokier wrote:
>>Marc Schneider wrote:
>> >    What  is  the  proper behavior if a client sends a request to a server
>> >    using   the   Expect   request-header   field  with  the  100-continue
>> >    expectation,  and  then pipelines another request before a 100 Contine
>> >    response  is  received and before the entity body of the first request
>> >    has been sent?
>> >    Is this legal? Are there any known clients that exhibit this behavior?
>>
>>It's not legal.  If the client doesn't see a 100 Continue response, it
>>can choose not to send the request body and close the connection.  It
>>can't omit the body and send another request, not even if it's already
>>seen a response from the server.
>>
>>Think about it: after the server sends an error response (without 100
>>Continue), the server cannot possibly know whether the client has sent
>>a request body or not.  It might be in flight in the network, because
>>the client is allowed to time out waiting for 100 Continue then send a
>>request body.  And because a request body is not syntactically
>>distinguishable from another request, the server must continue to
>>listen for a request body or close the connection.  Which means the
>>client must send it or close the connection.
>>
>>-- Jamie
>
>Marc Schneider
>Senior Software Engineer
>
>OPNET Technologies, Inc. (NASDAQ: OPNT)
>tel: +1.240.497.3000
>fax: +1.240.497.3001
><http://www.opnet.com/>http://www.opnet.com
>
>====================================================
>Register for OPNET's Online Technology Workshops
><http://www.opnet.com/TechWorkshops/>http://www.opnet.com/TechWorkshops/
>====================================================
>Register for OPNETWORK 2005 (August 22-26, Washington DC)
><http://www.opnet.com/opnetwork2005/>http://www.opnet.com/opnetwork2005/
>====================================================

Marc Schneider
Senior Software Engineer

OPNET Technologies, Inc. (NASDAQ: OPNT)
tel: +1.240.497.3000
fax: +1.240.497.3001
<http://www.opnet.com/>http://www.opnet.com

====================================================
Register for OPNET's Online Technology Workshops
<http://www.opnet.com/TechWorkshops/>http://www.opnet.com/TechWorkshops/
====================================================
Register for OPNETWORK 2005 (August 22-26, Washington DC)
<http://www.opnet.com/opnetwork2005/>http://www.opnet.com/opnetwork2005/
====================================================