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

Closed
daurnimator opened this issue May 31, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@daurnimator
Copy link

commented May 31, 2016

Continuing from http://www.rfc-editor.org/errata/eid4683

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

@reschke

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

@reschke

This comment has been minimized.

Copy link
Contributor

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?

@reschke

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2018

Actually, we have a similar situation for Accept:; see https://greenbytes.de/tech/webdav/rfc7231.html#header.accept:

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)
@daurnimator

This comment has been minimized.

Copy link
Author

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.