Re: XHR LC comments

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

That's understood. But what confuses me is the relation to XHR2 -- it 
seems that this WG is splitting time for work on two specs, where just 
working on XHR2 would be more useful.

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

Pointer, please?

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

Are you referring to: "14. If the user argument was not omitted and is 
not null let stored user be user  encoded using the encoding specified 
in the relevant authentication scheme or UTF-8 if the scheme fails to 
specify an encoding."?

This has two problems:

- it makes "stored used" an octet sequence, not a string.

- it simply doesn't work in practice, for instance for Basic Authentication

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

Well, we continue to disagree on this point.

The goal for examples should be to illustrate a specific feature, not to 
promote a specific coding practice (at least not when doing the latter 
affects the readability).

BR, Julian

Received on Monday, 26 May 2008 12:50:36 UTC