Issue 27 (PUT Idempotency)


a recent discussion over at the HTML WG's mailing list (starting with 
reminded me about our issue 27 

i27  	PUT idempotency  	RFC2616 - design - active


     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 

"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 
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,


Received on Saturday, 3 November 2007 12:29:33 UTC