Jonas Sicking wrote:
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.
Which would mean that a non-normative appendix telling the story about
the risk related to TRACE (and TRACK) would be helpful.
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.
For the record, I meant to say "TRACK", not "TRACE". But you are right,
even for "TRACE" it's not obvious except to people who already are aware
of the risk.
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)?
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.
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.
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.
BR, Julian
