Subject: Issue 27 (PUT Idempotency)

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Nov 2007 13:29:11 +0100

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Nov 2007 16:59:09 +1100

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

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