Browser caching does not work with ranges that don't start with zero
Categories
(Core :: Networking: Cache, enhancement, P3)
Tracking
()
People
(Reporter: docduo.io, Unassigned)
Details
(Whiteboard: [necko-triaged])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
Dear Firefox contributors,
Please, check the https request on https://app.fays.io/fd7be64d-ec78-4731-9dff-7b9c8088acf9
Tested on Firefox 72.0.2 (64 bits) for mac os X
Actual results:
The pdf document is never cached on Firefox but it is cached in Chrome or Safari.
Expected results:
Cache-control is set to "public, max-age=86400, immutable" so it should cache the range requests.
I check on https://open.spotify.com, and it appears they have the same issue! Please ask me for further details
Also on https://listen.tidal.com/
It looks like it is not caching maybe when there are CORS headers.. ?
Because on some other streaming services, caching works just fine (no CORS headers) https://www.jango.com/music/Leon+Bridges
Please have a look to the full description from Mozilla PDF Viewer: https://github.com/mozilla/pdf.js/issues/11599
![]() |
||
Comment 5•6 years ago
|
||
We never cache responses to range requests beyond 0-
by design:
There may already be a bug filed for this.
Comment 6•6 years ago
|
||
Honza, if it's on purpose, maybe this is an enhancement request to start caching subranges not starting with zero?
Related: bug 286082?
![]() |
||
Comment 7•5 years ago
|
||
(In reply to Andy Grover [:grover] from comment #6)
Honza, if it's on purpose, maybe this is an enhancement request to start caching subranges not starting with zero?
Related: bug 286082?
Yes and yes!
Comment 8•5 years ago
|
||
Updated•5 years ago
|
(In reply to Honza Bambas (:mayhemer) from comment #7)
(In reply to Andy Grover [:grover] from comment #6)
Honza, if it's on purpose, maybe this is an enhancement request to start caching subranges not starting with zero?
Related: bug 286082?
Yes and yes!
It would make sense to cache subranges not starting with zero, at least for mpeg / pdf files. There are examples of sites (e.g. Spotify, Mozilla PDF reader) that uses subranges requests for these content types and alternative browsers do accept caching those requests (I have tested Safari, Chrome, Opera).
Maybe is this a good start ?
Updated•5 years ago
|
Comment 10•5 years ago
|
||
I was really surprised when I stumbled upon the lack of caching for range requests and assumed it was a bug. I even put together a reproducible test case for it: https://cesiumjs.s3.amazonaws.com/caching/index.html
Comment 11•5 years ago
|
||
I apologize greatly for hitting send to soon and spamming everyone. I wanted to explain the main use case for the geospatial industry. Cloud-optimized geotiffs, https://www.cogeo.org/.
A Cloud Optimized GeoTIFF (COG) is a regular GeoTIFF file, aimed at being hosted on a HTTP file server, with an internal organization that enables more efficient workflows on the cloud. It does this by leveraging the ability of clients issuing HTTP GET range requests to ask for just the parts of a file they need. So instead of hosting pre-tiled raster/imagery data across hundreds of thousand of individual files, you can just host a single file and use range requests. The range requests are for internal "tiles" in the TIFF, so they are not random and well suited to caching.
The lack of caching in Firefox for range requests is a huge impediment to using this format for internet-based geospatial applications.
Sorry again for posting twice.
Comment 12•3 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 13•5 months ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #5)
We never cache responses to range requests beyond
0-
by design:
(In reply to Andy Grover [:grover] from comment #8)
bug where decision to only cache if range starts with zero was discussed
This doesn't sound like a reasoned decision, but just that at that point in time it was easier to only implement caching with "0-". So caching other ranges should be also possible and and improvement.
Description
•