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

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)."

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 it's not, it must use a UI 
that makes it clear that more than navigation is going to happen.

> 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. Of course you could define one.

> 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."

>> That concern could be addressed by making sure that accessing the same 
>> ping URI again could be detected, for example by adding a sequence or 
>> random number to it.
> 
> The whole point here is to make things simpler, and not require such 
> hacks and complications.

I was offering a workaround. As far as I can tell, it's not needed if 
Cache-Control is obeyed.

Do you have evidence that Cache-Control is broken in practice?

>>> one of "idempotent" vs "non-idempotent". The problems with using a 
>>> non-idempotent request are that idempotent methods aren't supposed to 
>>> have side-effects, whereas the whole _point_ of this request is a 
>>> side-effect;
>> ...a side effect the user shouldn't be made accountable for...
> 
> POST doesn't mean the user is accountable.
> 
> 
>>> POST doesn't mean the user is accountable.
>> Oh yes, it does in general.
>>
>> "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.

The UA represents me (the user) on the internet, and POST has completely 
vague semantics -- it's whatever the server implementor wants.

That the request was caused by the URI sitting in a ping attribute 
doesn't change it.

>> 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.

>> Whether a specific invocation of POST is safe or not does not depend on 
>> the HTML5 spec, but on the server that implements that resource.
>>
>> If a commercial site exposes a resource that, when being POSTed to (with 
>> an empty body), finishes a shopping transaction that will certainly not 
>> be "safe".
> 
> There is no security risk because this is only exposing a subset of 
> already-available capabilities (even with scripting disabled!).

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


>> Side note: I'm not sure what the point is to post to two mailing lists, 
>> but to only want responses on one of them.
> 
> I cross-post when I reply to multiple e-mails sent to mulitple mailing 
> lists (since otherwise I'd be replying to a different list than the mail 
> was sent to). Please only reply to one, so as to prevent issues with 
> people who are not subscribed to both.

I don't think this works in practice -- doing so what leave one copy of 
mail without a follow-up, while indeed there was one. If you don't want 
things to be posted to multiple mailing lists, then please don't post to 
multiple mailing lists in the first place.

Best regards, Julian

Received on Saturday, 3 November 2007 10:59:07 UTC