- 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
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 10:02:40 UTC