On Tue, 20 Mar 2007 16:05:26 +0100, Julian Reschke <[EMAIL PROTECTED]>
wrote:
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?
Well, the user agent has to follow a set of steps and at some point it has
to abort them... Although I suppose you could argue that since it's the
last step that phrase isn't really needed there... Removed in my local
copy.
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 we can't this standardization effort has been pretty pointless. Fun,
but pointless.
"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 says "unless it violates security... precautions".
[...]
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.
Even with UA interaction you would have exactly the same problem except
the user would also be annoyed at the UA for showing the stupid YES/NO
dialog he knows next to nothing about except for to hit YES... The whole
"user interaction model" is pretty broken imo.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
