- From: Jim Jewett <jimjjewett@gmail.com>
- Date: Mon, 24 Nov 2008 20:55:02 -0500
- To: public-html@w3.org
Ian Hickson wrote: > I don't understand how the semantics differ from POST, so I'm really the > wrong person to write that document. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 "The POST method is used to request that the origin server accept the entity enclosed in the request" -- but there is no entity, and that isn't what this ping is really about. "POST requests MUST obey the message transmission requirements set out in section 8.2" I think this can lead to over-reporting, but I don't see why it is specific to POST. "This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested." -- I think this is OK because of the "possibly" in "possibly unsafe", but there was concern. Julian Reschke wrote: > On the other hand, I do not understand how the semantics differ from > GET, so I'm not the right person to write it either. (1) Even if the official semantics don't differ, Ian has stated that the de facto effects of proxy caching make it unsuitable. (2) http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested." This accounting function means that this arguably does take a non-retrieval action on behalf of the user -- money changes hands. (I personally consider it acceptable, as the user isn't party to those transactions, but this was a major concern. It could become a problem if someone started usage based pricing on this, rather than on authenticated logins.) (3) http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol." "Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead." (Again, I'm not personally sure how sensitive it really is.) -jJ
Received on Tuesday, 25 November 2008 01:55:45 UTC