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

Re: On pipelining -Reply -Reply

From: David W. Morris <dwm@XPASC.COM>
Date: Fri, 21 Jan 2000 09:58:45 -0800 (PST)
To: Daniel Hellerstein <DANIELH@mailbox.econ.ag.gov>
cc: http-wg@cuckoo.hpl.hp.com
Message-ID: <Pine.GSO.4.05.10001210954280.21860-100000@shell1>


On Fri, 21 Jan 2000, Daniel Hellerstein wrote:

> >> 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. 

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
Received on Friday, 21 January 2000 18:02:20 EST

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