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

On Tue, 18 Mar 1997, Patrick McManus wrote:

> In a previous episode David W. Morris said...
> :: 
> :: 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)

OK, I see the point. I will update the next round of the UAHINT draft to
attempt clarification. The safe-ness in the past has always been based on
the postulate that if the initial request is safe because it has no side
effects that the user is responsible for then re-submission is also safe
but arguments have always cited the duplicate order issue (that infamous
unexpected pizza).  Assuming that the first POST would have a side-effect
which would be repeated if the POST is repeated is the unsafe-ness
concern. What I will say when edit this section will attempt to say that
resubmission of the request is SAFE. It will not be my intent to say that
the initial POST had no side-effect which the user will be held
accountable for only that the user's level of accountability won't change
as a result of resubmission. In general, I suspect the initial POST would
have had no side-effects but that really doesn't matter as long as a
subsequent POST wouldn't be additive.

> 
> ::  When designing the
> :: application, the author of the HTML must know if POST would be
> :: appropriate. 
> :: 
> 
> who said anything about html?

Sorry, that was a lazy of saying that the definition of the ua client
should be expected to understand the application and not misuse POST.

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

I guess I really don't feel strongly one way or the other about this
particular requirement. I don't recall it being raised last fall when the
GET/BODY vs. new header approach was debated. The problem is, as was
discussed by the WG and covered in Koen's draft (and mine by cut/paste),
that a new method either takes a kludge HTML hack or results in a lack of
compatiblity. (An a new method would be UNSAFE by HTTP/1.1 specification).

What would your reaction be to including the safe/uahint header on the
POST request? If the header said safe and the server said not-so, then
an error response would be required. How such a header were inserted
would be an equivalent hack at the UA level to adding a new method but
wouldn't effect proxies or servers.  The CGI program would have to check
for the header value.

Dave Morris

Received on Tuesday, 18 March 1997 23:18:12 UTC