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

Serve static Brotli compressed files #8062

Closed
1 task done
steverep opened this issue Jan 26, 2024 · 0 comments · Fixed by #8063
Closed
1 task done

Serve static Brotli compressed files #8062

steverep opened this issue Jan 26, 2024 · 0 comments · Fixed by #8063

Comments

@steverep
Copy link
Member

Is your feature request related to a problem?

Currently only the aiohttp client supports Brotli compression, and the aiohttp server is missing such capability for even just serving Brotli files that are statically compressed by the user (i.e. a file with the .br extension exists).

Describe the solution you'd like

For static requests, server should look for .br file extension in addition to .gz, and prefer Brotli over GZip if both exist.

I will submit a PR shortly for this. I opened the issue as a formality.

Describe alternatives you've considered

None

Related component

Server

Additional context

#2518 is obviously a similar feature request, but this request focuses on just starting with precompressed Brotli capability, and then expanding to dynamic compression.

Code of Conduct

  • I agree to follow the aio-libs Code of Conduct
webknjaz added a commit that referenced this issue Feb 14, 2024
)

Currently server only checks if static routes have a `.gz` extension and
serves them with `gzip` encoding. These changes do the same for `.br`
files with `br` encoding. Brotli is prioritized over gzip if both exist
and are supported by the client, as it should almost always be a smaller
content length.

I considered making a check for which is smaller if both exist, but
figured it wouldn't be worth the extra file system call in the vast
majority of cases (at least not for typical web formats). Users should
simply use gzip if it's smaller than Brotli for any file.

Resolves #8062 

Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: Sviatoslav Sydorenko <sviat@redhat.com>
steverep added a commit to steverep/aiohttp that referenced this issue Feb 14, 2024
…les (aio-libs#8063)

Currently server only checks if static routes have a `.gz` extension and
serves them with `gzip` encoding. These changes do the same for `.br`
files with `br` encoding. Brotli is prioritized over gzip if both exist
and are supported by the client, as it should almost always be a smaller
content length.

I considered making a check for which is smaller if both exist, but
figured it wouldn't be worth the extra file system call in the vast
majority of cases (at least not for typical web formats). Users should
simply use gzip if it's smaller than Brotli for any file.

Resolves aio-libs#8062

(cherry picked from commit dfc9296)

Co-authored-by: Steve Repsher <steverep@users.noreply.github.com>
Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: Sviatoslav Sydorenko <sviat@redhat.com>
webknjaz pushed a commit that referenced this issue Feb 14, 2024
…les (#8160)

Currently server only checks if static routes have a `.gz` extension and
serves them with `gzip` encoding. These changes do the same for `.br`
files with `br` encoding. Brotli is prioritized over gzip if both exist
and are supported by the client, as it should almost always be a smaller
content length.

I considered making a check for which is smaller if both exist, but
figured it wouldn't be worth the extra file system call in the vast
majority of cases (at least not for typical web formats). Users should
simply use gzip if it's smaller than Brotli for any file.

Resolves #8062

Co-authored-by: J. Nick Koston <nick@koston.org>
Co-authored-by: Sviatoslav Sydorenko <sviat@redhat.com>

(cherry picked from commit dfc9296)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant