On Sat, 21 Mar 2009 14:13:33 +0100, Giovanni Campagna
<scampa.giova...@gmail.com> wrote:
2009/3/20 Anne van Kesteren <ann...@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.
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
http://annevankesteren.nl/
