Re: [XMLHttpRequest] last call comments

On Tue, 20 Mar 2007 16:05:26 +0100, Julian Reschke <julian.reschke@gmx.de>  
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/>

Received on Tuesday, 20 March 2007 15:14:21 UTC