On Mon, 19 Mar 2007 22:29:36 +0100, Julian Reschke <[EMAIL PROTECTED]>
wrote:
I do agree that this is a good rule, but as far as I can tell, you
really need to state this (this==compliant implementations must
implement all MUST-level requirements).
Why?
2.1. Members of the XMLHttpRequest Object
"When method case-insensitively matches GET, POST, HEAD, PUT or DELETE
user agents MUST use the uppercase equivalent instead."
I know this is for compatibility with some broken implementations.
This is for compatibility with the web.
[...] If this is to stay, the set of affected method names should be
revisited. Do they all need to be on this list?
Feedback indicated that they should all be in the list, yes.
So do we have evidence of enough broken content using lowercased method
names so that this special case makes sense?
Implementors said they couldn't implement anything else.
"The syntax for the user or password arguments depends on the scheme
being used. If the syntax for either is incorrect per the production
given in the relevant scheme user agents must throw a SYNTAX_ERR
exception. The user and password must be encoded using the encoding
specified by the scheme. If the scheme fails to specify an encoding
they must be encoded using UTF-8."
I think this has been mentioned before: does this reflect what today's
implementations do for basic and digest?
I don't think so.
Hm. I'm wondering whether we need to label those things of which we know
that they *aren't* implemented that way accordingly.
It seems unwise to annotate (almost) every sentence...
Interesting.
If the major implementations do not do this consistently, this is IMHO a
clear indicator that we should define new methods with clear semantics
(removeHeader, getHeader, addHeader...).
It's a clear indicator that setRequestHeader() needs to be fixed. I
changed its definition now to match what Internet Explorer does. Just
ignoring a feature that has been implemented in different ways and going
with something now doesn't solve any problem.
Again, the current situation is problematic because clients can not
reliably predict what will happen when they call setRequestHeader.
Either get all vendors to implement the same thing, or add new methods
and leave setRequestHeader underspecified.
I'm aiming for the former.
"If the response is an HTTP redirect (status code 301, 302, 303 or
307), then it MUST be transparently followed (unless it violates
security, infinite loop precautions or the scheme isn't supported).
Note that HTTP ([RFC2616]) places requirements on user agents
regarding the preservation of the request method during redirects, and
also requires users to be notified of certain kinds of automatic
redirections."
To follow a redirect on a non-safe method without the user's consent
is forbidden in HTTP (see RFC2616, 10.2). No, notification is not
sufficient. And yes, this also applies to POST.
What text would you like us to use instead?
s/MUST/SHOULD/
There's already an indication of why this can fail. I think that's
sufficient.
Also state that this only applies to safe methods.
I think that's already clear enough as well.
[...]
It certainly is a problem. Again, see
<http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=237>.
I think that's more a problem with the site in question than with XHR. For
instance, with something as simple as a GET request you could steal
private data.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
