- From: Julien Pierre <jpierre@netscape.com>
- Date: Mon, 24 Jan 2000 18:48:50 -0800
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: Daniel Hellerstein <DANIELH@mailbox.econ.ag.gov>, http-wg@cuckoo.hpl.hp.com
- Message-ID: <388D0F12.D76950DC@netscape.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 Monday, 24 January 2000 18:51:47 UTC