- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Sat, 21 Mar 2009 14:13:33 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-webapps <public-webapps@w3.org>
2009/3/20 Anne van Kesteren <annevk@opera.com>: > On Fri, 20 Mar 2009 18:59:52 +0100, Giovanni Campagna > <scampa.giovanni@gmail.com> 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 > http://annevankesteren.nl/ > Giovanni
Received on Saturday, 21 March 2009 13:14:10 UTC