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

Quality values not considered when parsing Accept-Encoding request header #4726

Open
damb opened this issue May 6, 2020 · 0 comments
Open
Labels

Comments

@damb
Copy link

damb commented May 6, 2020

Quality values are not taken into consideration when parsing the Accept-Encoding request header field. The encoding chosen depends on the ordering in the ContentCoding enum:

class ContentCoding(enum.Enum):
# The content codings that we have support for.
#
# Additional registered codings are listed at:
# https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding
deflate = 'deflate'
gzip = 'gzip'
identity = 'identity'

and

accept_encoding = request.headers.get(
hdrs.ACCEPT_ENCODING, '').lower()
for coding in ContentCoding:
if coding.value in accept_encoding:
await self._do_start_compression(coding)
return

However, RFC 7231, section 5.4.3 states

4.  If multiple content-codings are acceptable, then the acceptable
       content-coding with the highest non-zero qvalue is preferred.

Though, within a note RFC 7231 also mentions that

Note: Most HTTP/1.0 applications do not recognize or obey qvalues
      associated with content-codings.  This means that qvalues might
      not work and are not permitted with x-gzip or x-compress.

Actually I'm not sure if this issue is a bug or rather a feature request. Though, I think that it would be a reasonable improvement. Would you accept a PR?

@damb damb added the bug label May 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant