Re: XHR LC comments

Anne van Kesteren wrote:
> On Tue, 27 May 2008 14:29:16 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> You're still avoiding the question whether the URL parameter can be an 
>> IRI. I would assume it can't, in which case the spec should require it 
>> to conform to RFC3986.
> 
> It can. I made the specification more clear on this.

- Is this actually implemented?

- If the URL parameter can be a IRI, then somewhere later on we need to 
state that it needs to be transformed to a URI before it's put on the wire.

>>>> This has two problems:
>>>>
>>>> - it makes "stored used" an octet sequence, not a string.
>>>  What is the problem?
>>
>> Well, octet sequences usually are not stored in strings but in byte 
>> arrays.
> 
> Yes, English is a flexible language :-)

Not sure what you're saying here. Note that I wanted to say "stored 
user", not "stored used" earlier on.

>> I think what the spec currently says is confusing, and likely to cause 
>> damage in practice.
> 
> I'm not convinced.

If people believe what it says, and use UTF-8 for Basic, it won't work. 
Sorry.

>>>> - it simply doesn't work in practice, for instance for Basic 
>>>> Authentication
>>>  You're not really helping finding the right solution here. This was 
>>> added for basic authentication if I remember correctly as it does not 
>>> specify any encoding.
>>
>> Sometimes there is no simple solution.
>>
>> Basic Authentication is not defined in terms of UTF-8, and, as far as 
>> I know, is not using it in practice, so suggesting that in XHR is a bug.
> 
>  From what I recall at least Firefox does it that way in practice. 
> Currently it does not give any indication what kind of character 
> encoding needs to be used so we picked the most obvious one.

Well, it's the wrong choice for Basic (does FF really do this????).

It's not that I wouldn't like it to be UTF-8. But it simply isn't.

 > ...

BR, Julian

Received on Tuesday, 27 May 2008 13:45:09 UTC