15312 2011-12-22 10:26:18 +0000 lowercasing requirement for Access-Control-Request-Headers harmful 2012-05-03 07:01:37 +0000 1 1 1 Unclassified WebAppsSec CORS unspecified All All RESOLVED WONTFIX http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-with-preflight-0 P2 normal --- 1 julian.reschke annevk ap mike public-webappsec dave.null oldest_to_newest 61935 0 julian.reschke 2011-12-22 10:26:18 +0000 "If author request headers is not empty include an Access-Control-Request-Headers header with as header field value a comma-separated list of the header field names from author request headers in lexicographical order, each converted to ASCII lowercase (even when one or more are a simple header)." The requirement to lower-case header field names is harmful; it introduces an inconsistency with other HTTP header fields (Vary, Connection) that is not needed, as header field names are supposed to compared case-insensitively anyway. 61936 1 annevk 2011-12-22 10:28:51 +0000 It's not inconsistent. They are case-insensitive. We're just conservative in what we transmit as header values. 61939 2 julian.reschke 2011-12-22 13:30:24 +0000 (In reply to comment #1) > It's not inconsistent. They are case-insensitive. We're just conservative in > what we transmit as header values. That doesn't make sense. Lower-casing something that is case-insensitive has nothing to do with being "conservative". If all header fields worked like this, it would be good and consistent. But it's the only one, which makes it harmful as implementations need to special-case something for zero benefit. 61942 3 annevk 2011-12-22 13:54:45 +0000 This is not about the header field. This is about the header field value. And it is only one whose value is case-insensitive. 61943 4 julian.reschke 2011-12-22 14:02:11 +0000 (In reply to comment #3) > This is not about the header field. This is about the header field value. And > it is only one whose value is case-insensitive. I understand it's about the field value. And, no, many header fields have case-insensitive field values (for instance, all which consists of a list of tokens). 61954 5 julian.reschke 2011-12-22 20:07:16 +0000 (In reply to comment #4) > (In reply to comment #3) > > This is not about the header field. This is about the header field value. And > > it is only one whose value is case-insensitive. > > I understand it's about the field value. > > And, no, many header fields have case-insensitive field values (for instance, > all which consists of a list of tokens). I would appreciate it if you didn't close the bug until we at least agree on terminology and facts. 62007 6 annevk 2011-12-24 13:41:54 +0000 So if token is case-insensitive, is Method too? http://tools.ietf.org/html/rfc2616#section-5.1.1 That seems weird. 62009 7 julian.reschke 2011-12-24 13:48:38 +0000 (In reply to comment #6) > So if token is case-insensitive, is Method too? > http://tools.ietf.org/html/rfc2616#section-5.1.1 That seems weird. No, method names are indeed case-sensitive; good catch, it indeed depends on context (for instance, in header field *parameters*, token on the left hand side are case-insensitive, while on the right hand side they are values and treatet case-sensitively). 67246 8 annevk 2012-05-02 17:29:33 +0000 We discussed this today at the WebApps meeting. The group agrees we should specify the value of the header in this manner. 67276 9 julian.reschke 2012-05-03 07:01:37 +0000 (In reply to comment #8) > We discussed this today at the WebApps meeting. The group agrees we should > specify the value of the header in this manner. It would be helpful to either include the rational, or a pointer to the meeting minutes.