Re: XMLHttpRequest Object feedback

Thanks!

Responses below -


On 2006/04/26, at 10:06 AM, Anne van Kesteren wrote:
>>
>> 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?

Argh. I so did not see that earlier :)

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

Ack.

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

I'll do it.

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

That would work. Actually, that would be a way to help fix (or at  
least notice) a lot of the underlying HTTP conformance problems  
without causing implementations with problems to be considered non- 
conformant to XHR, leading to CR problems...

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

I was thinking of something like

"UAs must not allow the Content-Length, Connection or Keep-Alive  
headers to be overridden."

instead of

"UAs must set the Connection and Keep-Alive headers as described by  
the HTTP specification, and must not allow those headers to be  
overridden."

because HTTP already tells UAs how to deal with these headers, and  
they don't always have to set them.

Same sort of text for the Host header.

>> Also, add TE to the list of headers that UAs MAY add.
>
> It MUST NOT be overriden?

Yes.

Cheers,

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Monday, 1 May 2006 17:18:22 UTC