On Fri, 13 Jun 2008, Julian Reschke wrote:
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.
+1
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.
This is just another proof that the spec should have two section, one
designed for authors, and one for implementation considerations.
I would add that it is entirely possible to reorganize the spec, even
after CR if no normative changes are done. Making the spec more clear as a
result of editorial work will vastly improve its quality, and ensure that
targeted parties will find what they need easily, and not relying on their
hands-on experience with different browser because the spec might be
opaque to some.
Cheers,
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
