httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <>
Subject Re: HTTP compliance and pipelined requests
Date Thu, 29 Jun 2000 09:21:22 GMT
On Wed, Jun 28, 2000 at 03:18:19PM -0400, Bill Stoddard wrote:
> I am looking for the correct interpretation of Section in RFC 2068. It states:
> "A client that supports persistent connections MAY "pipeline" its requests.  A server
> send its responses to those requests in the same order that the requests were received."
> My questions...
> 1. Is there a way for the server to determine if an HTTP/1.1 compliant browser is capable
> of pipelining requests?


>     My understanding is that there is no way for the server to know if an HTTP/1.1 browser
> can pipeline requests unless it actually starts sending pipelined requests.


> 2. Is it possible, upon receiving the first request from a client, to determine whether
> that client intends to or is capable of pipelining requests?
>     This is really the same question as above, just wanted to ask it in a different way.


> 3. Can a client pipeline some request and non pipeline other requests (all on the same
> connection) and still be HTTP/1.1 compliant?


> There are a couple of cases where the answer to this question is important.....
> case 1. - Bill, Ryan, Rasmus, et. al. in the past tossed around the idea of an request
> dispatcher. The distapcther receives a request and dispatches it to a back-end process
> running under a a security context (user id) suitable for that request. If two or more
> pipelined requests are dispatched to different back-end processes, then  it is possible
> for the responses to those requests to be sent out of order, unless the responses go
> through the dispatcher process.
> case 2 - If you are using an in-kernel static file cache (IBM's AFPA, khttpd, etc.) and
> pipelined requests are received, some of which are served out of the kernel cache and
> of which are served out of user space.  Unless special precautions are taken, responses
> pipelined requests could get out of order.
> If it were possible to determine, when the connection is first established between the
> browser and the server (or when the first request is received) that a browser is
> guaranteed to NEVER pipeline requests, then this would make handling these 'special
> precautions' trivial easy.  I don't think the server has a way of determining this though.

The server must always assume the client may pipeline, and hence you can never
take any shortcuts. One "exception" is if the server knows beforehand that the
connection will be closed after the response (either because the client sent
"Connection: close" or because the server decides to do so).



View raw message