httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: HTTP compliance and pipelined requests
Date Wed, 28 Jun 2000 20:09:09 GMT
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Wednesday, June 28, 2000 2:59 PM
> 
> ----- Original Message -----
> From: William A. Rowe, Jr. <wrowe@lnd.com>
> To: <new-httpd@apache.org>
> Sent: Wednesday, June 28, 2000 3:33 PM
> Subject: RE: HTTP compliance and pipelined requests
> 
> 
> > > From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> > > Sent: Wednesday, June 28, 2000 2:18 PM
> > >
> > > 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."
> >
> > If we were to implement pipelined -responses-, it seems to me
> > that the content length becomes somewhat more critical, given
> > the current discussions of the link-based/hook-based filters.
> >
> > If not content-length, then what terminates response A?
> > Multipart boundries?
> 
> Server closing the connection, content-length or 0 byte chunk 
> are all clues to the browser
> that the response is complete.

But the standard implies that closing the connection or a zero
byte chunk are terminal conditions.  It also implies that the
server can send a pipelined response of the requested files in
order as a single response (thinking of 10 small picture button
gifs, or something similar.)  For the -response- to be pipelined,
the content length must be known?

Bill

Mime
View raw message