2009/3/21 Anne van Kesteren <ann...@opera.com>: > 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.
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
