Re: [CORS] Charset in content type

2009/3/21 Anne van Kesteren <annevk@opera.com>:
> On Sat, 21 Mar 2009 14:13:33 +0100, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>>
>> 2009/3/20 Anne van Kesteren <annevk@opera.com>:
>>>
>>> I don't think that is the right place.
>>
>> Ok, just say that "implementation *must* pass the appropriate header
>> name and value to the network layer, which in turn *may* raise
>> NOT_SUPPORTED_ERR or SYNTAX_ERR if the header name / values are not
>> valid or parseable according to the appropriate standard".
>> This way you don't need to enforce validity in XHR, because that is
>> enforced in the network layer, but you don't need to define processing
>> for invalid combinations of headers either, and you're still
>> compatible with current XHR implementations.
>
> *may* is not good for interopability. I think we need to fix the value
> somewhere in the send() algorithm, as is already done for the charset
> parameter.

You could say *must*, but you would not be forward compatible with
HTTP extensions (only with HTTP/1.1) I think you should say
"Implementations *must* not use invalid values of known headers for
client-side processing but they *must* include them in the request"
In this way you don't only fix "Content-Type", but you also fix
"Cache-Control", "If-Modified-Since", "Accept-Language", etc.

>>>> field-value is a sequence of field-content, separated by linear white
>>>> space. The problem is that field-content is a sequence of TEXT (any
>>>> char) or token, separators and quoted-string.
>>>
>>> That seems pretty clear.
>>
>> And pretty useless too.
>
> It is not useless. It restricts DOMString quite a bit and ensures that the
> message conforms to the basic header/value syntax of HTTP.
>
>
>>>> This means that any sequence of chars, quoted or un quoted, tokenized
>>>> or not, is a valid field-content, and thus a valid field-value.
>>>> This is probably because each header enforces its own syntaxes, but I
>>>> don't feel much use in referencing field-value.
>>>
>>> Why not? It's a lot more limited than any Unicode character.
>>
>> No. The only characters not allowed are control characters in C0 block
>> and DELETE (U+007F) (if the appropriate charset is specified with
>> RFC2047 syntax)
>
> That is an escape syntax and therefore not literal Unicode characters that
> DOMString does allow.

You're right, you can only have ISO-8859-1 or manually encoded
characters. But still I'm not sure this is enough...

>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Giovanni

Received on Saturday, 21 March 2009 15:57:18 UTC