-
-
Notifications
You must be signed in to change notification settings - Fork 98
Implement format and compression inference from URIs for HTTP #5300
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
Conversation
📚 Documentation Preview🧹 Preview deployment has been cleaned up The documentation preview for this PR has been removed since the PR was closed. |
b8a7db2
to
bdf88be
Compare
3125f9d
to
0203839
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having read the changelog, it seems the logic now prefers the file extension over the content type. Is that the case? If not, we're good. But the Content-Type header is most of the time more accurate than the extension.
We could also allow the user to control the behavior in the future. For now, we just need to pick the most sensible setting.
@mavam See this for more info: https://tenzir.slack.com/archives/C04L7KXNZ9A/p1750758769154139?thread_ts=1750666508.920309&cid=C04L7KXNZ9A. TLDR: preference doesn't matter when they are both the same or we can only handle one of them. When they differ, we decided to go with filename for now and switch it if we encounter too many issues. |
That sounds fine to me. Important: this behavior must be well-documented. |
c678d35
to
71d383b
Compare
98a0c72
to
f2c4431
Compare
f2c4431
to
b79b758
Compare
b79b758
to
a994198
Compare
No description provided.