Re: Issue 27 (PUT Idempotency)

I personally think that @ping is an incredibly bad idea, so I really  
don't know where to start.

 From an HTTP perspective, pinging is not safe; the real problem here  
is that the Web is built from the ground up with the assumption of  
default safety, and this extension breaks that. But that's more an  
issue with HTML than HTTP. I.e., it's a user interaction issue.

I'd be very interested to see what the TAG has to say about this.

Cheers,


On 03/11/2007, at 11:29 PM, Julian Reschke wrote:

>
> Hi,
>
> a recent discussion over at the HTML WG's mailing list (starting  
> with <http://lists.w3.org/Archives/Public/public-html/2007Oct/ 
> 0337.html>) reminded me about our issue 27 (<http://www.w3.org/ 
> Protocols/HTTP/1.1/rfc2616bis/issues/#i27>):
>
> --
> i27  	PUT idempotency  	RFC2616 - design - active
>
> Description
>
>     It *appears* that RFC3253 changes the idempotency of PUT; is  
> this allowed? RFC3253 doesn't update or obsolete 2616...
>
>     I can see a situation where a 3253-naive client decides to  
> retry a timed-out PUT (after all, it's idempotent) and gets some  
> side effects it didn't bargain for.
> --
>
> I saw Roy talking about this issue over at rest-discuss (<http:// 
> tech.groups.yahoo.com/group/rest-discuss/message/7387>):
>
> "Just ignore the definition of idempotent in RFC 2616. Anything
> specified in HTTP that defines how the server shall implement the
> semantics of an interface method is wrong, by definition. What
> matters is the effect on the interface as expected by the client,
> not what actually happens on the server to implement that effect."
>
> ...which I understand that it's totally ok for a server to create  
> new version resources when PUT is applied to a resource.
>
> Now the HTML WG discussed the new A/@ping attribute (<http:// 
> dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? 
> rev=1.311&content-type=text/html;% 
> 20charset=iso-8859-1#hyperlink0>), which causes the UA to issue a  
> *POST* request to the ping target when you follow a link.
>
> The argument to make it POST instead of GET seems to be based on  
> the fact that performing the link auditing causes a side-effect,  
> and thus must use a non-idempotent method.
>
> I would argue that this is a misinterpretation of HTTP/1.1, because
>
> 1) The user is not requesting the side effect (well, unless the  
> UA's UI clearly indicates that this is not a "regular" link), and
>
> 2) The side effect itself affects a link tracking resource which in  
> general will not even be exposed by the server.
>
> Feedback appreciated,
>
> Julian
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 12 November 2007 06:02:36 UTC