Bug 15312 - lowercasing requirement for Access-Control-Request-Headers harmful
Summary: lowercasing requirement for Access-Control-Request-Headers harmful
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsSec
Classification: Unclassified
Component: CORS (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: This bug has no owner yet - up for the taking
URL: http://dvcs.w3.org/hg/cors/raw-file/t...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-22 10:26 UTC by Julian Reschke
Modified: 2012-05-03 07:01 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Reschke 2011-12-22 10:26:18 UTC
"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.
Comment 1 Anne 2011-12-22 10:28:51 UTC
It's not inconsistent. They are case-insensitive. We're just conservative in what we transmit as header values.
Comment 2 Julian Reschke 2011-12-22 13:30:24 UTC
(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.
Comment 3 Anne 2011-12-22 13:54:45 UTC
This is not about the header field. This is about the header field value. And it is only one whose value is case-insensitive.
Comment 4 Julian Reschke 2011-12-22 14:02:11 UTC
(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).
Comment 5 Julian Reschke 2011-12-22 20:07:16 UTC
(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.
Comment 6 Anne 2011-12-24 13:41:54 UTC
So if token is case-insensitive, is Method too? http://tools.ietf.org/html/rfc2616#section-5.1.1 That seems weird.
Comment 7 Julian Reschke 2011-12-24 13:48:38 UTC
(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).
Comment 8 Anne 2012-05-02 17:29:33 UTC
We discussed this today at the WebApps meeting. The group agrees we should specify the value of the header in this manner.
Comment 9 Julian Reschke 2012-05-03 07:01:37 UTC
(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.