Re: [CORS] Charset in content type

On Sat, 21 Mar 2009 14:13:33 +0100, Giovanni Campagna  
<> wrote:
> 2009/3/20 Anne van Kesteren <>:
>> 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  

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

Anne van Kesteren

Received on Saturday, 21 March 2009 13:35:31 UTC