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

On Sat, 3 Nov 2007, Julian Reschke wrote:
> Ian Hickson wrote:
> > We don't have to use an explicitly "safe" method because a ping="" is 
> > intrinsically safe in the HTTP sense.
> 
> But yet you stated in the previous mail that there may be case where 
> it's not:
> 
> "Actually I'd have thought the opposite was true -- in the two cases 
> that don't involve advertising, the tracking _does_ affect the user, and 
> presumably if one considers the safe vs unsafe distinction relevant 
> here, one would thus find it more important to use an unsafe method (and 
> also that it works more reliably than can be achieved with GET 
> requests)."

There are two types of requests for which one can use ping=""; those that 
directly affect the user, and those that don't. If we assume that the 
former is an unsafe action (in the HTTP sense) and the latter is a safe 
action (again in the HTTP sense) then we find that for the first one, we 
want to use an unsafe method, and for the second, it doesn't matter which 
method we use because the entire transaction is intrinsically safe 
regardless of the method used, since it does not imply anything that 
affects the user (by definition).


> So it seems it would be good to clarify whether following an audited 
> link is safe (in HTTP terminology) or not.
> 
> If it is, it should use a safe method.

If the entire HTTP request and response transaction is safe, then it 
doesn't matter what method we use, since using an explicitly "safe" method 
wouldn't make the transaction any safer (in the HTTP sense).


> If it's not, it must use a UI that makes it clear that more than 
> navigation is going to happen.

Yes, the spec already requires that.


> > We do have to use a non-idempotent method because a ping="" is 
> > non-idempotent by definition.
> > 
> > The two concepts are orthogonal.
> 
> Following that line of argument you need a method which is safe and 
> idempotent, which is not defined in RFC2616.

Indeed. In the absence of such a method, though, "POST" with a semantic 
that is defined to be safe in the HTTP sense seems to satisfy our needs.


> Of course you could define one.

It seems out of scope for HTML to define new HTTP methods.


> > I don't know how to make this any clearer, and I don't see anything in 
> > what you are saying that contradicts this other than your assertions 
> > that it isn't true.
> 
> I think you are reading more things into "idempotent" then you should.
> 
> Of course idempotent requests can have side-effects; the interesting 
> question is what kind of side effects these are. See 
> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27> and 
> <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>, where 
> Roy said:
> 
> "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."

If we follow Roy's reasoning, we should also ignore anything to do with 
"safe" vs "unsafe", in which case we're just left with our personal 
preferences as to which method to pick, and POST is as good as GET or 
DELETE or TRACE. Frankly, in that case, I'd rather pick POST anyway, since 
it is more likely to traverse transparent proxies than any method other 
than GET, and less likely to be affected by caching and replay bugs than 
GET. However, I don't think we should consider Roy's advice to ignore the 
spec to be any more normative than your advice or mine, so this is moot.


> > > "Implementors should be aware that the software represents the user 
> > > in their interactions over the Internet, and should be careful to 
> > > allow the user to be aware of any actions they might take which may 
> > > have an unexpected significance to themselves or others." -- 
> > > <http://tools.ietf.org/html/rfc2616#section-9.1.1>
> > 
> > This quote doesn't say that POST means the user is accountable.
> 
> Yes, it does. Sorry.

You are reading way more in between the lines of HTTP than is justified.

You are welcome to do so, but I'm not going to be convinced by lines of 
argument that require devining intent from vague statements in HTTP. I'm 
only going to take the text in the spec at face value.


> > > A server that receives a POST request has no way to decide how that 
> > > method invocation was initiated; the fact that a/@ping caused it is 
> > > not visible in the request.
> > 
> > We could add an HTTP header to make it obvious, if that would help. 
> > However, it's rather moot, since you can already cause a Web page to 
> > POST to a site without ping="" and without the user's knowledge.
> 
> Yes, but that's saying "it's already broken somewhere else, so it's ok".  
> I believe that's the wrong approach.

Trying to prevent leaks through a cracked tile in the barn roof is a 
futile exercise when the barn door is wide open. Unless we have any 
intention of fixing the many ways in which POSTs can be done on the user's 
behalf without user intervention, I don't see any reason to worry about 
adding a harmless way of doing a content-less POST.


> Please educate me: how do I silently do a POST without having scripting 
> enabled?

Try test.html in this directory:

   http://damowmow.com/playground/demos/http/002/

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 3 November 2007 22:17:32 UTC