clarify upgrade token case-sensitivity

[reschke]

https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0390.html

[reschke]

Citing @royfielding selectively:

They are case-sensitive.

I do not necessarily disagree, but don't see anything saying that, except for the use of the "token" ABNF production. Should we clarify?

[reschke]

Also, if we agree on the case-sensitivity, we should raise a bug report against RFC 6455.

[reschke]

Erratum against RFC 6455: https://www.rfc-editor.org/errata/eid5453

[reschke]

See also mail wrt ws-over-http2 at https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0169.html

[royfielding]

Hmm, while the token is case-sensitive, that does not imply that a recipient must limit itself to case-sensitive match (unless, for some bizarre reason, two tokens that differ by case are distinctly implemented by the recipient).

[royfielding]

IOW, we should ideally write that the token is intended to be case-sensitive and senders SHOULD (or MUST) generate the same case as the registered token, but a recipient MAY interpret a received token case-insensitively (for robustness) when there is no potential for misinterpretation.

This is hop-by-hop, so no worries about intermediary confusion.

[reschke]

How is a recipient supposed to know whether there is no potential for misinterpretation?

If we allow the registry to contain "a" and "A" with different meanings, it can't know for sure.

If we don't allow that, the upgrade token essentially is case-insensitive, no?

[royfielding]

Because the recipient is going to choose one and signal what it is to the client. It isn’t going to choose something it hasn’t implemented, so it either has more than one implementation for different cases, or one for all cases, or one for the right case and ignores badly cased tokens. Forcing a given choice on the recipient in this situation is not going to improve interoperability because both ends have to agree.

[reschke]

Yes, but if the client wants "A", and the server understands that as "a", and those are indeed different protocols, don't we have an interop problem?

It seems to me it would be far easier to say that the value is to be compared case-insensitively, and just adjust the IANA registration to deal with that.

[royfielding]

Okay, you have convinced me. I don't want this to be confused with other uses of the protocol ABNF rule, but I don't see any value in registering case-confusing tokens.

[mnot]

In the meantime, in the registry:

WebSocket | The Web Socket Protocol |   | [RFC6455]
websocket | The Web Socket Protocol |   | [RFC6455][RFC8441]

[reschke]

@royfielding - so are you now ok with #131 ?

[royfielding]

I updated the PR to make protocol-name case-insensitive (with preferred case registered).

[ioquatix]

Is this official yet?

[reschke]

What do you mean by "official"?

[ioquatix]

Is it published in any RFC? Should we depend on this behaviour?

[reschke]

The specs are currently in "IETF Last Call", ending June 10. See https://lists.w3.org/Archives/Public/ietf-http-wg/2021AprJun/0154.html.