httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordi Ros" <>
Subject Re: HTTP compliance and pipelined requests
Date Wed, 28 Jun 2000 22:28:06 GMT
Hi all,

My concern is the same as yours, Bill. I'm not very familiar with the
dispatcher problem but yes you are right, in-kernel mini servers such as
kHTTPd may suffer from the synchorinization of HTTP responses. For the
current version of kHTTPd this is not a problem since it only supports HTTP
1.0. However, next versions aim to HTTP1.1 and at this point the issue will
come. If both Apache and kHTTPd are coexisting in the same server sending
responses to the client, some kind of synchronization is needed to handle
pipelined responses.

>From section 4.4 of RFC 2616 basically we have four ways to know the end of
a response: content-length, server closing the connection, 0 byte chunk,
multipart/byterange. All of them except the server closing the connection
require parsing the HTTP payload. So one way to solve the issue is to
implement a mini-parser in the kHTTPd that intercepts and parses the
responses coming from Apache to know where is the end. But this does not
look like a very efficient solution. Any comments on this would be very

Also, I wold like somebody to make comments on the following quote taken
from the book "Internetworking with TCP/IP" 4th Edition:

"To allow a TCP connection to persist through multiple requests and
responses, HTTP sends a length before each resonse. If it does not know  the
length, a server informs the client, sends the response, and then closes"

Is this true for Apache? According to the emails you have been sending
Apache provides others ways other that closing of the connection such as the
0 byte chunk. Any comments on this quote are very welcome too. Thanks!!



Jordi Ros                                             email:
Electrical and Computer Engineering      voice (work): (949) 622 0991
University of California, Irvine                  www:

----- Original Message -----
From: "Bill Stoddard" <>
To: <>
Sent: Wednesday, June 28, 2000 12:18 PM
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
> 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.
> Thoughts?
> ________________________________________________
> Bill Stoddard

View raw message