Re: XHR LC comments

Anne van Kesteren wrote:
> 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.

Unfortunately.

>>>> c) Structure: It would be nice if Section 4 had more structure. 
>>>> Rightnow 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.

At this point, I'm not sure why we're bothering with XHR1 at all. It is 
*not* what the current implementations do anyway.

>>> Yes, as stated it must be a subset that matches what 
>>> XMLHttpRequestrequires 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

Thanks.

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

That's not sufficient, and not what I asked for. Please make up your 
mind whether it's a URI or a IRI, and then cite accordingly.

>>>> 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 
>>> HttpOnlycookies I rather not remove that. I think it will be clear 
>>> enough forpeople 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

Thanks.

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

I'd prefer it to be moved somewhere else, but at least it's an improvement.

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

But that totally depends on the authentication scheme. I think you're 
confusing layers here.

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

Thanks. It currently says:

"Note: The empty string is legal."

Maybe you could add "and represent an empty header value"?

>>>> "Serialize data into a namespace well-formed XML document and 
>>>> encodedusing 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.

Sounds like something that should be tested. Silent data loss is a bad 
thing, and I really don't believe that any existing content relies on that.

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

So is it legal for implementations to populate certain headers upon 
object creation?

>>>> "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 
>>>> (notSet-Cookie2) spec as well (RFC2109).
>>> I believe it used to do that and it was pointed out that 
>>> thatspecification is not useful in practice and would actually do 
>>> more harmthan 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.

Thanks.

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

How is this relevant for demonstrating the output format for 
getAllResponseHeaders()?

>>>> "status of type unsigned short, readonly
>>>>
>>>> On getting, if available, it must return the HTTP status code sent 
>>>> bythe server (typically 200 for a successful request). Otherwise, if 
>>>> notavailable, 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.

That's better, although still a bit confusing.

>>> All requirements from HTTP are taken over unless explicitly stated so 
>>> Idon'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.

Well, it is addressed in HTTP.

BR, Julian

Received on Friday, 16 May 2008 11:14:58 UTC