<audio> and <video> elements do not set Accept-Encoding header
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
People
(Reporter: denschub, Unassigned)
References
Details
Attachments
(1 file)
|
336 bytes,
text/html
|
Details |
When fetching the sources for <audio> or <video> elements, it appears like Firefox does not set an Accept-Encoding header, resulting in the connection never using any compression.
While filing this bug, the Bugzilla showed me bug 614760, which actually looks like we made this change deliberately, so now I have to explain myself a bit more. I discovered this while diagnosing a WebCompat issue, where Firefox failed to show media while Chrome was fine. This turned out to be a server-config issue, and the server simply rejects all non-gzip requests, but the fact that Chrome, and Safari (did not yet test in other browser) do set an Accept-Encoding header makes me wonder if we should as well.
Given the original decision was made 10 years ago, I figured it might be worth opening a new issue. I have not nearly enough background on this to have an opinion here, though, so I'm looking for a second opinion.
|
||
Comment 1•4 years ago
|
||
The original reasons stated in bug 614760 are still valid. Media files are already heavily compressed. Adding gzip compression on top of it makes no sense whatsoever. gzip is highly useful for plain text files like HTML, JavaScript, CSS etc., but not for PNG nor audio/video.
The problem you mention is that the server is configured to refuse any plain non-gzip requests. From what I know about HTTP specs, that is actually a spec violation. gzip is purely optional. This is simply a server mis-configuration, and should be fixed on this level.
This is an advocacy issue. You were completely right to point this out to the server webmaster.
Suggest WONTFIX or moving to BugZilla product "Web Compatibility".
|
||
Updated•4 years ago
|
|
Reporter | |
Comment 2•4 years ago
|
||
Well, we already resolved the issue on that website from a WebCompat point of view. The point of opening the issue was to check if there's a reason behind that difference between all other browsers and Firefox, because it caused confusion for me and at least 3 more people (the site's owner, and two of the admins at their hoster).
Looks like this is a WONTFIX then.
Description
•