Re: Pipelining and Expect: 100-continue interaction

 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/
====================================================