[feat] Use Accept-Encoding to allow data compression #755
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#755
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The idea
As a webmaster, I see Akkoma in my logs and see it does not use data compression (accept-encoding header). All modern HTTP clients support this feature, so it is common to also support this on the server side.
In our case we recently decided to block all requests with HTTP/1.0 and those that are not offering to use data encoding. Due to that, we saw a few RSS feed readers showing up, and Akkoma.
Example from log (ip and instance masked), the 426 error means it is blocked:
2024-04-21T20:24:21+00:00 426 1.2.3.4 "GET /cheat-sheets/curl/ HTTP/1.1" 16 "-" "Akkoma 3.12.2; https://masked <masked>" TLSv1.3/TLS_AES_256_GCM_SHA384 0.000 .
I did a quick look in the code, but as I'm not familiar with it, I couldn't find the HTTP handler.
My suggestion would be to enable at least Gzip, but preferably Brotli (better savings) and possibly zstd (not as common, yet).
Thanks for your consideration!
The reasoning
Save data traffic, which is beneficial for everyone involved (data centers, publishers, and clients). Especially as this involves every single HTTP request the software performs, it will add up over time considering that on a HTML/CSS/SVG/JS often the savings are great.
Have you searched for this feature request?