W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: TRACK, was: LC comments.

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 13 Jun 2008 11:46:50 -0700
Message-ID: <4852C09A.7030402@sicking.cc>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Anne van Kesteren <annevk@opera.com>, Yves Lafon <ylafon@w3.org>, public-webapps@w3.org

Julian Reschke wrote:
> Jonas Sicking wrote:
>> ...
>>> TRACK is specific to a legacy version of IIS, and not documented 
>>> anywhere (right?).
>>>
>>> So, I think the proper way to deal with this is either to be silent, 
>>> or to add this as an implementor's note in an appendix.
>>>
>>> Requiring implementors to put in workarounds for something that is 
>>> neither documented nor shipping in current server versions is really 
>>> hard to accept.
>>
>> Given that all browsers today have chosen to block this method, and 
>> are likely to continue to do so, it seems prudent to tell users of the 
>> interface about this, so that they don't try to use the method.
> 
> I don't see why.
> 
> A client that tries TRACE is likely to exploit an IIS weakness, and if 
> the UA blocks it, the client is getting what it deserves (an exception).

Or they have implemented something completely unrelated in their server 
that just happens to be called TRACE and are confused why they can't 
interact with it using XMLHttpRequest.

> On the other hand, why would we want to hardwire this requirement into 
> the spec? As far as I can tell, mentioning TRACE in this prominent place 
> already causes way more confusion than not mentioning it would ever cause.

I think that is due to insufficient explanation in the spec of why the 
method is there.

>> 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.
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
3. Many UAs would likely miss some of the security aspects and would
    therefore be exploitable.

/ Jonas
Received on Friday, 13 June 2008 18:50:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:25 GMT