Re: Feedback on the ping="" attribute (ISSUE-1)

There has been a LOT of discussion on the HTTP method that should be  
used for the ping attribute. I think that there are a lot of good  
reasons on both sides. It seems to me that the two arguments could be  
summarized (with a lot of hand waving) as:

Anti-POST -> Systems use POSTs for a number of things that have real  
impacts on users (like transfering money from point A to point B) that  
they would not want to happen as a side effect of following a link.  
Using a GET ensures that the ping does not have these sorts of  
effects, provided the implementer of the resource follows the HTTP RFC  
correctly.

Pro-POST -> From the point of view of the system implementing the ping  
resource, a POST is the appropriate method to use.

I'm skipping a lot of points. I think that its worth noting the  
following:

1) That, except for the verbs, the requests should be identical in  
both situations
2) That, regardless of the verb used, we are relying on the  
implementer of the resource to follow the relevant specs &  
recommendations and to "do no evil" as nothing would prevent side  
effects from happening on a GET.

Let me suggest that there are 2 solutions to the impasse:
1) Add language to the HTML5 spec to make it clear to implementers of  
ping resources what the expected behaviour of posts to that resource  
will do.
2) Allow POST and GET as values in ping. Each instance would determine  
the method to use for each of the following URIs (until the next POST  
or GET is encountered). The default would be one of the two (my vote  
is for POST).

The first gives those who which to follow the rules guidelines on what  
they should and shouldn't do with PING resources. Its reasonable to  
assume that anyone who is going to follow the specs will find this  
useful and those who would do their own thing regardless of what any  
spec or recommendation says. The second allows us, without any real  
cost (?), to defer the decision of which method to use to author time  
with a reasonable default.

Received on Tuesday, 13 November 2007 17:53:48 UTC