This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"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.
It's not inconsistent. They are case-insensitive. We're just conservative in what we transmit as header values.
(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.
This is not about the header field. This is about the header field value. And it is only one whose value is case-insensitive.
(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).
(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.
So if token is case-insensitive, is Method too? http://tools.ietf.org/html/rfc2616#section-5.1.1 That seems weird.
(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).
We discussed this today at the WebApps meeting. The group agrees we should specify the value of the header in this manner.
(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.