Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 29 Jun 2000 02:21:22 -0700
From: "Life is hard, and then you die" <ronald@innovation.ch>
To: new-httpd@apache.org
Subject: Re: HTTP compliance and pipelined requests
Message-ID: <20000629022122.B20500@innovation.ch>
Mail-Followup-To: new-httpd@apache.org
References: <016d01bfe135$9e2f75d0$c1e01b09@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <016d01bfe135$9e2f75d0$c1e01b09@raleigh.ibm.com>;
 from stoddard@raleigh.ibm.com on Wed, Jun 28, 2000 at 03:18:19PM -0400

On Wed, Jun 28, 2000 at 03:18:19PM -0400, Bill Stoddard wrote:
> I am looking for the correct interpretation of Section 8.1.2.2 in RFC 2068. It states:
> 
> "A client that supports persistent connections MAY "pipeline" its requests.  A server MUST
> 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?

No.

>     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.

Correct.

> 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.

No.

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

Absolutely.

> 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 back
> 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 some
> of which are served out of user space.  Unless special precautions are taken, responses to
> 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).


  Cheers,

  Ronald