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

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:
> 
> 	* Client gets a page via post.. it's marked Safe
> 	* Client reloads page page.. no UA confirmation is
> asked.. this time a side effect does occur (do to some application
> logic.. time of day perhaps) and the response is marked Safe: no..
> 	* User doesn't reload again.. has no idea that the last load
> of page had a different impact than previous loads..

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.  When designing the
application, the author of the HTML must know if POST would be
appropriate. 

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

> The recently mentioned draft-ietf-http-uahint-00.txt suffers the same
> limitation. 

At this stage, vis a vis 'safe/notsafe', the uahint proposal is only
supposed to be a syntax change from Koen's draft to what ever value or
flaws exist should be the same.

Dave MOrris

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