- From: Adam van den Hoven <adam.vandenhoven@gmail.com>
- Date: Tue, 13 Nov 2007 09:49:49 -0800
- To: Jon Barnett <jonbarnett@gmail.com>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "public-html@w3.org" <public-html@w3.org>
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