RE: Summing up on visibility(?)

Mark,
I was just commenting on your example using PUT, and your point that the intermediary knows that the server will not do any "further dispatching". What I am pointing out is that PUT, as defined by RFC 2616, does not guarantee that no "further dispatching" is carried out (where by "dispatching" I mean any additional processing other than setting a new value for the resource).

Ugo

> -----Original Message-----
> From: Mark Baker [mailto:[email protected]]
> Sent: Wednesday, January 08, 2003 7:34 PM
> To: Ugo Corda
> Cc: [email protected]
> Subject: Re: Summing up on visibility(?)
> 
> 
> On Wed, Jan 08, 2003 at 11:52:22AM -0800, Ugo Corda wrote:
> > > This is in contrast to if the ugly string was just opaque 
> > > data on which
> > > no further dispatch decision could be made.  Then the 
> > > intermediary would
> > > be able to conclude that the client was trying to set the 
> state of the
> > > identified resource to the value in that string, even if it 
> > > didn't know
> > > anything about the string or its meaning.
> > 
> > Why? PUT is idempotent but not safe. RFC 2616 says 
> "HTTP/1.1 does not define how a PUT method affects the state 
> of an origin server".
> 
> Sorry Ugo, I don't understand the question, or the relevance of that
> quoted text to my assertion.  Can you elaborate?
> 
> FWIW, if it's a PUT issue, I could construct a GET example that
> demonstrated the same thing, just with the string in the URI, 
> instead of
> in the body.
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>