Re: [XHR2] Comments on the 7 September working draft

On Mon, 13 Sep 2010 20:10:23 +0200, Sergiu Dumitriu  
<sergiu.dumitriu@gmail.com> wrote:
> The refactoring is not quite equivalent:
>
> if(this.readyState == this.DONE && this.status == 200) {
> ...
> }
> processData(null);
>
> processData will be called even when this.readyState != DONE.

Oops. Fixed.


>>> - "The request URL, The URL used in the request" -> Could it be made
>>> more obvious that this is the resolved, absolute URL, and not the
>>> relative one passed as an argument?
>>
>> Why does that matter here?
>
> Less ambiguity?

I do not think there is any, but I changed it anyway.


>>> - "The upload events flag, Used to determine whether to send upload
>>> progress events for cross-origin requests. The flag is either true or
>>> false" -> Is it only for cross-origin requests? The send() algorithm
>>> doesn't say so. Perhaps this is more correct:
>>>> The *upload complete* flag, Used to determine when to stop sending
>>>> upload progress events. The flag is either true or false.
>>>> The *upload events* flag, Used to determine whether to send upload
>>>> progress events. The flag is either true or false.
>>
>> The send() algorithm does say so. It is only used for cross-origin
>> requests.
>
> OK. Still, maybe the proposed text for the upload complete flag could be  
> used?

Done.


>>> - The code sample at the end needs some kind of introduction.
>>
>> Isn't it self-explanatory? I.e. with the comments?
>
> Yes it is; I was talking about something like the text in the examples  
> from the first section:
>
> "Some simple code showcasing what happens when setting the same header  
> twice:"

Fair enough, added.


>> See above, would differ for abort().
>
> How exactly? abort() doesn't read the error flag.

Yeah, you are right.

There seems to be a problem with invoking abort() and then invoking open()  
 from an event handler. I wonder why I never caught that before. I guess  
this needs another look. *sigh*


> OK, I think I get it now. When registering listeners, even if the  
> request will fail since it's not allowed by the remote server, the  
> events fired might still give out some information about the server. Am  
> I right?

Yes, that it exists.


>>> - "If authentication fails, Authorization is not in the list of author
>>> request headers, request username is null, and request password is
>>> null, user agents should prompt the end user for their username and
>>> password." + "They are also not prompted for cross-origin requests."
>>> => should a same-origin condition be included in the first text?
>>
>> Fixed, simplified the text a lot too.
>
> OK with the new text.
>
> I just realized that AnonXHR is not mentioned here. I guess anonymous  
> requests should never prompt for username/password, right?

Anonymous requests are cross-origin by design.


>>> - "If the user agent supports HTTP State Management it should persist,
>>> discard and send cookies (as received in the Set-Cookie response
>>> header, and sent in the Cookie header) as applicable." -> Shouldn't
>>> the anonymous flag be mentioned here?
>>
>> Maybe this paragraph should just be dropped? HTML5 does not have an
>> equivalent sentence. FWIW, CORS is very clear on the behavior here.
>
> Personally, I'd keep it there. It was present in XHR1, and CORS deals  
> only with cross-origin requests.

I mean that no other specification dealing with requests specifically  
calls out sending cookies in the request. That is already part of the  
cookies specification. We should of course still call out when cookies are  
not to be included or when they are not to be set, but just in general  
repeating what the cookies specification says does not seem useful. (It  
would also be removed from XMLHttpRequest Level 1.)

This applies also to the text on proxies.


>> Two spaces everywhere it is.
>
> Almost, there's still the comment inside the processData function in  
> Section 1.

Heh, fixed.


>>> Section 4, FormData:
>>> - Shouldn't a read method be included?
>>
>> Why?
>
> In case different code components fill in parts of the request data and  
> they want to check that they're not overriding somebody else's data, in  
> case that some field names should have only one value, or in case one  
> component wants to change/remove the value placed by an earlier  
> component (which calls for a remove method as well, leading to a  
> full-fledged map interface :( ). Maybe it gets too complex, so it should  
> be left as it is now, complex scenarios should be handled with a custom  
> object which is then converted to a FormData

Yeah. We can always make it more complex later.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 14 September 2010 11:34:54 UTC