Anne van Kesteren schrieb:
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?
It seems to me that many specs phrase it that way, but maybe that's
cosmetic.
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.
It now says:
"If the header argument is in the list of request headers the user agent
must either use multiple headers, combine the values or use a
combination of those (section 4.2, RFC 2616) and abort these steps.
[RFC2616]"
What's the "and abort these steps" about?
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.
I'd prefer the latter, unless we can get UAs fixed. Can we?
"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.
I don't think it's clear at all, unless you already know it. Currently
the description doesn't even use the term "safe", so how can it be clear?
[...]
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.
No, the problem is the UA which issues an unsafe request without user
interaction.
Best regards, Julian
