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).
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.
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.
BR, Julian
