httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: HTTP compliance and pipelined requests
Date Thu, 29 Jun 2000 12:56:32 GMT

HI Bill -
As far as I know:
1) No, 2) No 3) Yes.

It is for these reasons that the OS/390 version of Afpa (FRCA) as well as
the "Domino Go WebServer"  Work Load Manager (WLM) enabled "scalable mode"
OS/390 use a technique where the network connections are kept by a control
region.   In the case of afpa/frca, that is in the kernel.  In the case of
DGW, the Queue Manager address space keeps the network connection.

For Afpa/FRCA, we have the capability to "give back" the socket to the
stack after completion of a request on a persistent connection.
For DGW "scalable mode", the back end Queue Server address space will tell
the QM when it is done processing a request, i.e. it also has a "give back"
capability.  This is built on top of the asynch i/o support I did for the
OS/390 V2R8 version of DGW.   [And I have been following the Apache group
discussion of asynch i/o, and MPM w.r.t. Apache 2.x]


John M. Thompson
IBM HTTP Server for OS/390 (IBM WebSphere)
Apache for OS/390
IBM Corporation
Lotus Notes: John Thompson/Poughkeepsie/IBM
VM: thompson at kgnvmc

"Bill Stoddard" <> on 06/28/2000 03:18:19 PM

Please respond to

To:   <>
Subject:  HTTP compliance and pipelined requests

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

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
precautions' trivial easy.  I don't think the server has a way of
determining this though.


Bill Stoddard

View raw message