Re: XHR LC comments

On Fri, 16 May 2008 13:14:12 +0200, Julian Reschke <julian.reschke@gmx.de>  
wrote:
> At this point, I'm not sure why we're bothering with XHR1 at all. It is  
> *not* what the current implementations do anyway.

It's setting a baseline for implementations. As with most legacy features  
without a specification, implementations differ a lot in the details.  
Typical usage of the API more or less works the same anywhere, but if we  
only defined that we might as well publish an empty specification and  
reference some brief description of XMLHttpRequest somewhere on the Web.


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

I deferred this issue to HTML5 for now by referencing the recently  
introduced definition of "same origin" there. That makes more sense  
because if any changes to that definition are made there it would also  
affect XMLHttpRequest.


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

It does depend on that and that is mentioned.


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

Done.


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

Since you raised this comment on various threads I'll address it in one of  
the other ones.


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

It's relevant in case people copy the example, which I expect to happen.  
In case they do that and the example would've used synchronous code they  
end up with UI-lockup et cetera, which would be bad.


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

Received on Monday, 26 May 2008 12:31:00 UTC