Re: draft-holtman-http-safe-01.txt

In a previous episode David W. Morris said...
:: 
:: On Tue, 18 Mar 1997, Patrick McManus wrote:
:: 
:: > The draft introduces Safe as a response header which is of course not
:: > initiated in any way by the client.. this leaves no method for the
:: > client to send a request to the server (with a body) that Mandates
:: > that they consent to no side effects.. leading to some particularly
:: > gruesome scenarios:
[..]
:: The safe: yes (and uahint variation) response header mean that any future
:: resubmit of the request will be safe. It says nothing about the request
:: which was just made which may have had a side effect.


That's not how I read section 3:

--
3 The Safe response header

 This header is proposed as an addition to the HTTP/1.x suite.

 The Safe response header field indicates whether the corresponding
 request is safe in the sense of Section 9.1.1 (Safe Methods) of the
 HTTP/1.1 draft specification [1].
--

It speaks very specifically that the safe response header field talks
about the corresponding (i.e. current) request.. I think making any
assumptions about future request/response pairs requires clairvoyance
(and the Note further in section three claims that it can do this
clairvoyance)

::  When designing the
:: application, the author of the HTML must know if POST would be
:: appropriate. 
:: 

who said anything about html?

It is not unusual for us to release a c/s pair  and
have other folks independently develop their own client side
interfaces without our knowledge.. it'd be extremely kind if they
could have a method that would guarantee no side effects for them
should we upgrade the server side to change it's behavior without
telling them.. (which is sort of hard, as we don't know they are there!)

In short if we've got a CGI that makes side effects we make damn sure
it's input comes from POST not from GET before doing it.. even if
we've coded the client side to use POST.. because someone else out
there experimenting against our service and using GET shouldn't be
able to impact the environment.. this whole system works fine, we just
need a GET with a message body.

:: > 
:: > In addition, there needs to be some way for the UA to send a request
:: > that doesn't allow side effects to occur (the current semantics of
:: > GET) for safety's safe, instead of just determining whether or not
:: 
:: The type of request sent by a client is determined by the HTML the user
:: is responding to. It is the responsiblity of the application designer
:: to match the method with its characteristics.  Are you anticipating
:: that future clients will offer the user a choice other then GET for
:: manually typed URLs? 

It seems like a much more flexible choice than designing the system so
they can't. Tthe whole UA world isn't html oriented browsers that can
draw distinctions between "typed it in" and "clicked on it"..



-Patrick
--
Patrick R. McManus - Applied Theory Communications -	Software Engineering
http://pat.appliedtheory.com/~mcmanus			Programmer Analyst
mcmanus@AppliedTheory.com	'Prince of Pollywood'	Standards, today!
*** - You Kill Nostalgia, Xenophobic Fears. It's Now or Neverland. - ***

Received on Tuesday, 18 March 1997 10:04:07 UTC