W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2000

Re: On pipelining -Reply -Reply

From: Julien Pierre <jpierre@netscape.com>
Date: Mon, 24 Jan 2000 18:48:50 -0800
Message-ID: <388D0F12.D76950DC@netscape.com>
To: "David W. Morris" <dwm@xpasc.com>
CC: Daniel Hellerstein <DANIELH@mailbox.econ.ag.gov>, http-wg@cuckoo.hpl.hp.com
Hi,

"David W. Morris" wrote:

> There is no reason for the 'server' which happens to be extended by a CGI
> or other bit of active code to have to enforce compliance ... that is the
> responsiblity of the author of the application. And it is the application
> which will break or otherwise offend the user.  The protocol specifies the
> correct and safe way to produce well behaved applications.  During the
> years of producing the HTTP RFCs, it was always understood that a content
> provider could take the risk of changing server side state ... and a
> common example is a hit counter on a page. But would you want to insist
> that pipelining be disabled because a non-semantic state change occured
> with a different result?
>
> I wouldn't.

I don't think anyone was suggesting that pipelining should be disabled for
such applications; simply that the server should process the requests in
serial order so as to preserve the expected behavior.

I tend to agree with that. I considered multithreaded execution of pipelined
requests on a single connection for the Netscape Enterprise Server. However,
it turned out that most deployed applications are not idempotent (irrespective
of the request method), so in practice this would create more trouble than it
was worth. Also, the extra load on the server, in terms of buffer space and
extra threads, was significant.

The cases where processing requests out of order would benefit most are when
high-latency content is involved. Let's say for example there is a CGI request
sent by the browser to update the HTML content of a frame, followed by
requests for static images that were part of a document. The CGI will take
some time to execute, and obviously with the current version of HTTP/1.1 that
will hold up the images. What is really needed to benefit is a way for the
server to send replies out-of-order . So the static images could be delivered
right away while the CGI application is running. I have heard that HTTP/NG may
actually resolve that issue but I haven't checked into it yet.

--
for a good time, try kill -9 -1


Received on Tuesday, 25 January 2000 02:49:45 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:35 EDT