Re: [CORS] Charset in content type

2009/3/20 Anne van Kesteren <>:
> On Fri, 20 Mar 2009 18:59:52 +0100, Giovanni Campagna
> <> wrote:
>> You may just enforce validity of known or possibly unsafe headers
>> (Content-Type being the most important)
> 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.

>>>> Or actually, they don't per current spec, but I think they should.
>>>> (and anyway RFC2616 is not very clear about the field-value production)
>>> How is it unclear?
>> 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.

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

> --
> Anne van Kesteren


Received on Saturday, 21 March 2009 13:14:10 UTC