W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: XHR LC comments

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 16 May 2008 12:07:16 +0200
To: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.ua8rqewy64w2qv@annevk-t60.oslo.opera.com>

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



> 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  

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


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

>>> "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
Received on Friday, 16 May 2008 10:07:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC