Re: XMLHttpRequest Object feedback

On Fri, 21 Apr 2006 18:29:06 +0200, Mark Nottingham <mnot@yahoo-inc.com>  
wrote:
> See section 7.2.1; something like
>
> "XHR operates across entity bodies, as defined by [RFC2616, section  
> 7.2.1]; that is, transfer-encodings are applied to request bodies  
> submitted to send(), as well as response bodes made available."

I used "entity body" for responseText like:

    <p>If the <code><term>readyState</term></code> attribute has a value  
other
     than 3 (Receiving) or 4 (Loaded), it MUST be the empty string.  
Otherwise,
     it MUST be the fragment of the entity body received so far (when
     <code><term>readyState</term></code> is 3 (Receiving)) or the entity  
body
     (when <code><term>readyState</term></code> is 4 (Loaded)), interpreted
     using the character encoding specified in the response, or UTF-8 if no
     character encoding was specified. Invalid bytes MUST be converted to
     U+FFFD REPLACEMENT CHARACTER.</p>

I made the reference to RFC 2616 in a separate definition section.


> Ack. BTW, the issues list isn't obviously linked from the WG's home page.

It's right under Documents at http://www.w3.org/2006/webapi/ (first hit  
for "issue") or did you mean the Member home page?


>>> WRT URIs, what should happen when I pass it a URI with a fragment  
>>> identifier?
>>
>> Do you perhaps know what implementations do?
>
> I can't imagine that they'd do much, but I'll test and report back.  
> Assuming they don't, it might be good to say something to the effect  
> that fragment identifiers either
>    a) aren't allowed
>    b) might not be supported

Please e-mail your findings in a separate e-mail. Based on the results we  
should probably be able to come up with some reasonable requirements on  
UAs and authors...


>>> When talking about redirects, it would be really nice to remind  
>>> implementers (probably non-normatively) that HTTP has requirements  
>>> about method preservation and getting approval for the user for the  
>>> various codes; see http://www.mnot.net/javascript/xmlhttprequest/
>>
>> Suggestions for text? I also wonder what kind of implications it would  
>> have for implementations given that currently most seem to ignore it.
>
> "Implementers should note that HTTP places requirements on  
> implementations regarding the preservation of the request method during  
> redirects, and also requires users to be notified of certain kinds of  
> automatic redirections."

   <p>If the response is an HTTP redirect (status code 301, 302, 303 or  
307),
    then it MUST be transparently followed (unless it violates security or
    infinite loop precautions). Note that HTTP [RFC2616] places requirements
    on UAs regarding the preservation of the request method during  
redirects,
    and also requires users to be notified of certain kinds of automatic
    redirections. Any other error (including a 401) MUST cause the object to


> WRT how it affects implementers, I think that's a question of whether  
> the WG intends to test the requirements it inherits from HTTP (and other  
> specs) during the CR phase.

Guess so.


>>> Content-coding is a property of the content (entity, representation,  
>>> whatever) itself -- just like content-type and content-language -- and  
>>> automatically handling it breaks layering (which is OK, as long as you  
>>> do it explicitly). This means that if decoding is handled  
>>> automagically, the appropriate part of the Content-Encoding header  
>>> should probably be stripped, so the app doesn't get confused.
>>
>> What do you mean?
>
> In HTTP, Content-* headers are entity headers -- they describe  
> properties of the content explicitly. As such, they're not transparently  
> handled by the implementations; if I send an entity and it's got a gzip  
> encoding, I expect the guy on the other side to get a gzip encoding as  
> well.
>
> All that said, many people find it convenient for the implementation to  
> handle content-encoding automatically.
>
> I think the implication of this is that *if* the WG decides that  
> content-encoding can be handled by the implementation automatically,  
> there should be some control offered to the user over whether or not it  
> happens.
>
> The real trick for the WG might be in deciding what the default of that  
> control is.

Thanks, this makes it more clear. Are you willing to raise another issue  
or should I do it? If you have more fancy tests available by the way for  
this, they are welcome :-) The default probably has to be based on what  
currently works.


> [...]
> "Otherwise, the nominated request header field value MUST be set to  
> value. If the nominated request header field already has a value, the  
> new value SHOULD be combined with the existing value, as specified by  
> [RFC2616 Section 4.2]. Implementations MAY replace an existing value  
> (instead of combining it with the new value) if the nominated request  
> header field value is not specified as a comma-separated list."

Use this text, thanks!


>>> Say something to the effect that if the UA has a cache, it MUST honour  
>>> Cache-Control request headers sent with setRequestHeader(). This  
>>> allows the application to control the cache.
>>
>> So we need more text besides "In particular, UAs MUST NOT automatically  
>> set the <code>Cache-Control</code> or <code>Pragma</code> headers to  
>> defeat caching [RFC2616]."?
>
> Yes. Something like "UAs that implement a cache should honour request  
> cache-control headers." Note the lower-case SHOULD; HTTP already  
> requires them to be honoured.
>
> Based on my testing, implementations don't do this today. It would be  
> very good if they do; as it is, developers don't have any control of the  
> local cache.

Perhaps we can cover this in the testsuite?


> [...]
> The text reads as if persistent connection support is required, when  
> HTTP does not require it. It also normatively re-states the requirements  
> of HTTP, which isn't good specification practice.

Well, another way to set these headers is letting the author do it. So I  
can see why there's a requirement on UAs here from that perspective...


> It should just be:
>
> "UAs MUST NOT allow the Connection, Keep-Alive and Content-Length  
> headers to be overridden."
>
> Using the same logic, the requirement about the Host header should be
>
> "UAs MUST NOT allow the Host header to be overridden."
>
>>> "set" should probably be "use", and Content-Length should be in there  
>>> too. In fact, I'd require UAs to set Content-Length; while  
>>> theoretically you can chunk a request body, there are some practical  
>>> interop problems with doing so.
>>
>> Could you elaborate on that?
>
> Not applicable any more -- see above.

[...]


>>> What about automatically setting headers to do with delta encoding  
>>> (RFC3229)? TE (for transfer encoding negotiation)? Content-MD5 (for  
>>> request body integrity)? Meter (HTTP hit metering from caches)? The  
>>> UA-* request headers? MUST NOT is too strong a prohibition for  
>>> automatically-set headers; I'd suggest SHOULD NOT. (The response shown  
>>> in the "Manipulating response headers" example is actually impossible  
>>> for conforming implementations to see; you need to send TE to get a  
>>> Transfer-Encoding back).
>>
>> Would it work if I removed "Transfer-Encoding: chunked" from the  
>> example? And what are your suggestions for those other headers?
>
> My suggestion would be to weaken "User agents MUST NOT set any headers  
> other than the headers set by the author using this method" to SHOULD  
> NOT.

Ok, made that change for now as it sounds reasonable to me.


> Also, add TE to the list of headers that UAs MAY add.

It MUST NOT be overriden?


> [...]
>
> setRequestHeader() is the problem. Something like this would improve it;
>
> "UAs MAY set the Authorization header, based upon the operation of HTTP  
> Authentication [RFC2617 ref]. If a challenge from the server is  
> encountered, credentials SHOULD be generated based upon the values of  
> the username and password specified by open(). UAs MUST NOT set the  
> Authorization header solely because open() contains a username/password;  
> it should only be set as part of the protocol described by HTTP  
> Authentication [RFC2617 ref]."
>
> That probably needs some massaging to take account of the precedence  
> rules for sourcing username and password. It's tricky, because the UA  
> can optimistically send Authorization, based upon previous challenges  
> sent; you just don't want the UA sending it without having seen a  
> challenge.

Used that text for now and added a note about rewording.


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

Received on Wednesday, 26 April 2006 17:06:16 UTC