Case sensitivity of extension point token ids

[mnot]

E.g., range-units. Working on #133, it's not clear.

[mnot]

Same question could be asked for transfer-codings, content-codings, cache-control directives, and a few other places. I suspect interop for case-varying things is not great in at least some of these places.

[wtarreau]

FWIW in haproxy the match for these is case-insensitive. The rationale here is that the Connection field contains tokens, which are header field names thus are case-insensitive, thus all other ones supposed to be tokens as well are de-facto case-insensitive. From a code perspective it makes sense since the same matching functions are used. BTW, 7234#5.2 says cache-control tokens are case-insensitive.

[wtarreau]

However for us the "q=" prefix for preferences is case-sensitive. Maybe that's wrong, I don't know :-/

[mnot]

Yep. This is mostly a reminder for me to do some testing :)

[wtarreau]

I know, hence my inputs as well :-)

[craigpratt]

I think the reality is that implementations generate (and many servers expect) the bytes range unit in lower case. But I'll have to look at some of the impls I'd looked at when considering the addition of a new range unit...

[mnot]

Overview:

• methods: defined as case-sensitive
• field names: defined as case-insensitive in messaging, not semantics
• transfer-codings: defined as case-insensitive
• content-codings: not defined defined elsewhere
• language tags: defined as case-insensitive
• range-units: not defined
• authentication scheme: defined as case-insensitive
• media types: defined as case-insensitive
• cache directives: defined as case-insensitive

[mnot]

Based upon the above, I suggest we:

• make both content-codings and range-units case-insensitive, as this appears to be an oversight
• explicitly make field names case-insensitive in semantics

[mnot]

Also, in most places the same sentence is used to encourage registration; we should do that where applicable.