Subject: Re: On pipelining -Reply -Reply

From: "Daniel Hellerstein" <[email-masked]>
Date: Fri, 21 Jan 2000 12:48:11 -0500

>> server side includes in GETs of html documents might cause 
> changes in  "state" variables.).
>>That's not allowed. GET is idempotent which implies it must
>be stateless.
>You should be using POST for that sort of thing.

Interesting point.

But does that mean that  proper http/1.1 server-software should
enforce this? That server software should somehow not allow
GET to invoke scripts, etc. that might change "state" variables. 
That's a tough requirement (from a server author's point of view).

Also, what, if a response has an immediate exipiration (say, it's
generated by
a script that changes state variables, or it's generated from an SHTML
resource that
contains hit counts, time of day, or other dynamic elements).

My reading of idempotency suggests that in such cases the
"statelessness"
of GET is no longer a constraint.

---

From: "David W. Morris" <[email-masked]>
Date: Fri, 21 Jan 2000 09:58:45 -0800 (PST)

> of GET is no longer a constraint. 

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.

Dave Morris

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 21 Jan 2000 11:11:51 -0800

(mailing list name 'cuckoo' -> 'hplb' again).

There's no point in restricting side effects in general; the
idea was to restrict side effects that somehow mattered! And
whether or not it matters depends on the application. For the
traditional web browsing application, clicking on a link twice,
refetching a web page, or even prospectively fetching a page
that you think someone *might* want, using GET to mirror a site,
etc ... those shouldn't have significant side effects.

For interactions between subsequent requests and pipelining,
since it is the client that decides whether to pipeline,
it is also the client that has the responsibility for
deciding whether pipelining matters.

For web browsing, there's no real problem: the only
state change where consistency matters is the interaction
between the POST from a form being filled and the subsequent
GETs that are triggered by embedded URLs in the content
that is returned from the post.

For other applications that are being built on top of
HTTP, there must be some agreement between client and
back-end application as to what the dependencies and
transaction semantics must be; the HTTP server needn't
enforce these, since the clients have complete control
over whether they ATTEMPT pipelining.

I suppose you might want to note that intermediaries
shouldn't introduce pipelining (e.g., by prospectively
guessing what URLs might appear in subsequent content
and prefetching them!) but otherwise, this is a client,
not a server, responsibility (IMO).

Servers need not serialize processing pipelined requests;
clients that care shouldn't pipeline.

Larry
-- 
http://larry.masinter.net

---

From: [email-masked] (Julien Pierre)
Date: Mon, 24 Jan 2000 18:48:50 -0800

Hi,

> that pipelining be disabled because a non-semantic state change occured

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