Re: spec review: ping attribute

On Oct 28, 2007, at 12:21, Julian Reschke wrote:

> Henri Sivonen wrote:
>> On Oct 27, 2007, at 19:12, Julian Reschke wrote:
>>> Geoffrey Sneddon wrote:
>>>> Having read this entire thread, I don't see why anything is  
>>>> actually wrong. In this context the difference between GET and  
>>>> POST is negligible — both can technically be used to do what is  
>>>> desired, though using GET would be breaking RFC 2616 (or rather,  
>>>> breaking a SHOULD NOT). If we
>>>
>>> No, sorry, that's incorrect.
>>>
>>> If you want to do something silently (without the user's  
>>> consent), you simply have to use a safe method.
>> So would you ban XHR POST and script-initiated form submissions?
>
> I would want the XHR spec to clarify that it's not OK to initiate  
> unsafe methods without the user's consent.

What kind of UI would you suggest for obtaining consent e.g. in a  
case where a Web app contains a big editable form and JavaScript  
saves a backup copy of the form silently to the server side from time  
to time to prevent data loss in case the user navigates away from the  
page or the browser crashes?

> I would also deprecate script-initiated form submissions from  
> something like onload().

Deprecation doesn't protect anyone's security. Either it is so bad  
that it'd need to be unsupported or it isn't so bad.

>> The ping attribute does have the same security risks that cross- 
>> domain XHR POST with empty entity body would have if the access- 
>> control Method-Check weren't there. That is, if a POST handler has  
>> been programmed to trigger stuff on mere POST without a body, a  
>> malicious ping attribute could be used to trigger that action.
>>> And if you consider the desired effect non-safe (which I don't),  
>>> then the consequence is that you just can't do it.
>> It is about idempotent vs. non-idempotent and side effects.
>> If you are counting ad impressions, clearly you don't want to
>>  a) count Google Web Accelerator (or similar) prefetches
>>  b) leave impressions uncounted due to an intermediate cache  
>> satisfying the request.
>
> Yes. But the same problem can (and is) already used without "ping",  
> and even if you use "ping", you still could do it with a safe  
> method (HEAD/Cache-Control:no-cache).

That might work and could be a tad safer. It isn't in any way  
theoretically pure from the RFC 2616 point of view, though, to make  
HEAD and GET have different semantics beyond the response body presence.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 28 October 2007 12:07:43 UTC