Re: XHR LC comments

Julian Reschke wrote:
>>> b) Algorithms: the spec uses a method to describe algorithms that IMHO 
>>> is extremely hard to read (see for instance send() method). This maybe  
>>> good for implementors, but seems to be bad for everybody else. 
>>> Minimally, the lists should be structured for better readability.
>> Could you elaborate on what kind of change you envision? I'm not  
>> surehow they are not structured right now.
>
> An example would be steps 8..11 in the description of open():
>
> - these steps deal with credentials, and the whole list would be more
> readable if each group of steps that belong together would me structured
> that way;

Since this is the second Last Call and credentials are already following  
each other (and the same for other similar steps) I've decided not to  
change this.


>>> c) Structure: It would be nice if Section 4 had more structure. Right 
>>> now it's ugly to navigate and refer to.
>> This is better in XMLHttpRequest Level 2. I rather not revise  
>> thatentire section editorially as it might introduce new errors.
>
> But then, it makes a comparison with XHR2 harder. Please reconsider.

Given that XMLHttpRequest Level 2 has more changes than just this in terms  
of structure I don't think it will help that much.


>> Yes, as stated it must be a subset that matches what XMLHttpRequest 
>> requires from the eventing and core specifications.
>
> Then it would be clearer if it said "the subset" instead of "some  
> subset".

Changed:

   http://dev.w3.org/2006/webapi/XMLHttpRequest/#dependencies


> Well, if we're talking about URIs (and I think we do), then we need to
> refer to RFC3986 grammar and comparison rules.

Ok, referenced RFC3986 as well.


>>> Besides that: this may be a non-optimal example unless we can point  
>>> toa definition of "HttpOnly cookies". Can we?
>> I don't believe we can, but since this was put in mostly for HttpOnly 
>> cookies I rather not remove that. I think it will be clear enough for 
>> people reading the document.
>
> So why don't we refer to the specification for httpOnly? Do you consider
> it a problem that it's a Microsoft document?

I added a pointer to http://msdn.microsoft.com/en-us/library/ms533046.aspx


> As TRACK doesn't seem to be documented anywhere, and not implemented in
> current IIS versions anymore, I'd really like to see this made a foot
> node. The way it's written now is just totally confusing to every reader
> who doesn't know the full story around it.

I added a note.


>>> "If the user argument was not omitted and is not null let stored  
>>> userbe user  encoded using the encoding specified in the relevant 
>>> authentication scheme or UTF-8 if the scheme fails to specify an 
>>> encoding."
>>>
>>> Why is XHR talking about the encoding here? Is "stored user" a  
>>> stringor a byte array?
>>>
>>> (same for password)
>> They're a string (in the API).
>
> When they are a string, then taking about character encoding doesn't
> make any sense here.

Actually, since you need to encode them for the request it does.


>>> "If the value argument is null terminate these steps. (Do not raise an 
>>> exception.)."
>>>
>>> This makes it impossible to set empty headers, which are allowed in 
>>> HTTP. Even worse, it silently fails.
>> Empty headers can be set using the empty string, no? Not raising an 
>> exception is consistent with implementations and I don't think  
>> itmatters much as it doesn't have any effect.
>
> Sorry, was reading one thing, but thinking about something else.
>
> Thinking of it, could you please add a clarification that setting to an
> empty string is legal, and MUST NOT be ignored? I recall that
> Microsoft's original XHR (ActiveX) implementation got that wrong, not
> setting the header at all.

I added a note to that effect as it is already normatively required.


>>> "Serialize data into a namespace well-formed XML document and encoded 
>>> using the encoding given by data.inputEncoding, when not null, orUTF-8  
>>> otherwise. Or, if this fails because the Document cannot beserialized  
>>> act as if data  is null."
>
> Does anybody rely on that? I would be very suprised.

I don't know, but it seems safest to not require changes here for  
compatibility.


>>> "If no Content-Type header has been set using setRequestHeader()append  
>>> a Content-Type header to the list of request headers with avalue of  
>>> application/xml;charset=charset  where charset is theencoding used to  
>>> encode the document."
>>>
>>> This will result in an invalid Content-Type header if the UA has 
>>> initialized the headers with a default (which I think the  
>>> speccurrently allows; and at least one UA was reported to do). See  
>>> commentabove about header handling.
>> Rephrased.
>
> Pointer?

   http://dev.w3.org/2006/webapi/XMLHttpRequest/#send


>>> "If the user agent supports HTTP State Management it should persist, 
>>> discard and send cookies (as received in the Set-Cookie andSet-Cookie2  
>>> response headers, and sent in the Cookie header) asapplicable.  
>>> [RFC2965]"
>>>
>>> This should probably include a reference to the Set-Cookie (not 
>>> Set-Cookie2) spec as well (RFC2109).
>> I believe it used to do that and it was pointed out that that 
>> specification is not useful in practice and would actually do more harm 
>> than good. I'm not really sure what to do here.
>
> Well, the one that is not used in practice is RFC2965, not RFC2109. That
> being said, you probably need to reference both.

Ok done.


>>> "// The following script:
>>> var client = new XMLHttpRequest();
>>> client.open("GET", "test.txt", true);
>>> client.send();
>>> client.onreadystatechange = function() {
>>>   if(this.readyState == 3) {
>>>    print(this.getAllResponseHeaders());
>>>   }
>>> }
>>>
>>> // ...should output something similar to the following text:
>>> Date: Sun, 24 Oct 2004 04:58:38 GMT
>>> Server: Apache/1.3.31 (Unix)
>>> Keep-Alive: timeout=15, max=99
>>> Connection: Keep-Alive
>>> Transfer-Encoding: chunked
>>> Content-Type: text/plain; charset=utf-8"
>>>
>>> I think examples like this would be more readable (and take lessspace)  
>>> when using the syncr. mode.
>> I would like to avoid encouraging authors to use the synchronous API.
>
> Disagreed. I think readability and compactness is more important here.

I disagree. It would also change the example as then the header  
information would only be made available after all data has been  
downloaded rather than when the header information is available.


>>> "status of type unsigned short, readonly
>>>
>>> On getting, if available, it must return the HTTP status code sent by 
>>> the server (typically 200 for a successful request). Otherwise, if not 
>>> available, the user agent must raise an INVALID_STATE_ERR exception."
>>>
>>> This may be incorrect when the UA caches (304 vs 200).
>>
>> That's why it says typically.
>
> Hm, no.
>
> When the UA caches, and the server sent 304, the client will potentially
> see a 200. This would contradict what *this* paragraph says.

I fixed this by saying that in case of user agent conditional requests the  
user agent must act as if the server gave a 200 response in case of a 304  
response.


>>> "statusText of type DOMString, readonly
>>>
>>>      On getting, if available, it must return the HTTP status textsent  
>>> by the server (appears after the status code). Otherwise, if not 
>>> available, the user agent must raise an INVALID_STATE_ERR exception."
>>>
>>> Really? It seems to me that if somebody really implements this,clients  
>>> are likely to break. Why not allow an empty string here?
>
>> This is what clients have implemented as far as I can tell. Though the 
>> HTTP status text could be the empty string, if that's what you mean...
>
> Does the "if not available" apply to any of the existing
> implementations? Why would it be "not available"? Please clarify.

Added "(request is not initiated for instance)".


>> All requirements from HTTP are taken over unless explicitly stated so I 
>> don't think this is needed.
>
> Well, the spec repeats lots of things specified somewhere else already.
>
> The warning from the HTTP spec is relevant and should appear here, as
> XHR is related to UAs, and existing UAs are known to ignore this
> security consideration.

In that case I'd be even more hesitant to repeat it in XMLHttpRequest as  
it seems like something HTTP should try to address one way or another.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Friday, 16 May 2008 10:07:41 UTC