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

On 09/14/2010 01:34 PM, Anne van Kesteren wrote:
> 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.

OK.

>>>> - "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.

OK.

>>>> - "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.

OK.

>>>> - 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.

OK.

>>> 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*

Indeed, this will have weird results:

1. open()
2. Add listeners
3. send()
4. abort()
5. In the readystatechange listener, call open() and send()
6. abort continues, and sends the next events: abort, loadend, but now 
the object's state is wrong: the state is not DONE, there might be 
network activity, the error flag is not set.
7. The abort algorithm sets the state to UNSENT, although a request is 
in progress.

One option would be to change the open() algorithm, so that step 15 
aborts both the send() and abort() algorithms, and also the "request 
error" algorithm. But this means that listeners won't get all the events 
(this is also true if the open method is called when a request is 
already in progress).

Allowing open() to be called at all times makes it almost impossible to 
fix this error, so another option is to not allow open to be called when 
some other algorithms are in progress.

>>>> - "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.

Indeed.

>>>> - "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.

OK.

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

OK.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Received on Tuesday, 14 September 2010 16:00:59 UTC