Re: TRACK, was: LC comments.

>>>> If you want to put this as a Note in the spec, or as a normative 
>>>> part of the spec matters less to me. However I don't see a reason 
>>>> not to make it normative since it's not going to change for any web 
>>>> browser.
>>>
>>> It just doesn't belong here.
>>>
>>> UAs are already allowed to reject anything they want for security 
>>> concerns, so making it *mandatory* to do so for a method that even 
>>> isn't documented is really strange.
>>
>> That line of reasoning would mean that we shouldn't put any security 
>> restrictions in the spec and then just tell UAs to deal. There are 
>> several downsides with that:
>>
>> 1. Users would get annoyed when running into the restrictions that don't
>>    show up in the spec.
> 
> Like PROPFIND not working (IE7), or silently rewritten to "GET" or 
> "POST" (Opera)?

We hope that they will fix this. As we hope that all implementations 
will eventually be compliant with the spec.

> Yes, I do agree that explaining this is useful, I just don't see why 
> it's necessary to make it a normative requirement, and put it into the 
> API documentation.
> 
> An appendix would be completely sufficient.

See the other two points below.

>> 2. It gets harder to build future specs on top of this spec since you
>>    can't by looking at the XHR spec tell what works and what doesn't
> 
> It doesn't tell you that anyway, as some implementors have chosen a 
> white-list approach to extension methods.

We hope that they will fix that.

>> 3. Many UAs would likely miss some of the security aspects and would
>>    therefore be exploitable.
> 
> In this case, it's not the UA, but IIS 5.1 that is exploitable.

It's the combination of IIS+UA that is exploitable. In firefox when we 
run into situations like this we try to get the problem fixed at the 
source (in this case IIS). However if that is not possible we are forced 
to patch it in firefox instead. The goal is to protect our users, not 
play the "he did it, she did it" game.

Additionally your argument only applies to this one security feature. 
Not the feature of blocking the "host" header in setRequestHeader for 
example.

/ Jonas

Received on Friday, 13 June 2008 20:50:24 UTC