Re: a/@ping discussion (ISSUE-1 and ISSUE-2), was: An HTML language specification vs. a browser specification

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