Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 7230 A transfer-parameter of `q` should not be allowed #15

daurnimator opened this issue May 31, 2016 · 4 comments


None yet
3 participants
Copy link

commented May 31, 2016

Continuing from

In the current spec, nothing is said about how to handle transfer-parameters.
Notably, nothing is said about the case sensitivity of the parameter key.

This results in a conflict with the TE header: if you see a "q" token,
you cannot know if it is a transfer-parameter vs a t-ranking.

It is noted that the "q" token is case insensitive in section 4.3.

When multiple transfer codings are acceptable, the client MAY rank
the codings by preference using a case-insensitive "q" parameter


This comment has been minimized.

Copy link

commented Jun 20, 2018


This comment has been minimized.

Copy link

commented Jun 25, 2018

OK. An edge case of an edge case.

Note that among the currently registered transfer codings, none defines parameters.

Drastic options might be:

  1. Disallow parameters on transfer codings (and thus also on content codings)
  2. Remove quality values on transfer coding negotiation.

More realistic:

  • in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE".

Should I make a proposal for this?


This comment has been minimized.

Copy link

commented Jun 26, 2018

Actually, we have a similar situation for Accept:; see

Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".

@reschke reschke closed this in 2bb7e1f Jun 29, 2018

reschke added a commit that referenced this issue Jun 29, 2018

Merge pull request #109 from httpwg/reschke-eid4683
State that transfer codings should not use parameters named "q" (closes #15)

This comment has been minimized.

Copy link

commented Jul 4, 2018

Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.