Open Bug 1615698 Opened 5 years ago Updated 2 years ago

Browser caching does not work with ranges that don't start with zero

Categories

(Core :: Networking: Cache, enhancement, P3)

73 Branch
Unspecified
macOS
enhancement

Tracking

()

UNCONFIRMED

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

Component: Untriaged → Networking: Cache
OS: Unspecified → macOS
Product: Firefox → Core
Summary: Cache is not working for range request with Cache-control set to public → Browser caching does not work with range request set and CORS
Version: 72 Branch → 73 Branch

Please have a look to the full description from Mozilla PDF Viewer: https://github.com/mozilla/pdf.js/issues/11599

Severity: normal → critical

We never cache responses to range requests beyond 0- by design:

https://searchfox.org/mozilla-central/rev/cc0f9906505d0ffa0d3a29a80142379e21cb5fb2/netwerk/protocol/http/nsHttpChannel.cpp#4069-4071

There may already be a bug filed for this.

Honza, if it's on purpose, maybe this is an enhancement request to start caching subranges not starting with zero?

Related: bug 286082?

Flags: needinfo?(honzab.moz)

(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!

Type: defect → enhancement
Flags: needinfo?(honzab.moz)
Summary: Browser caching does not work with range request set and CORS → Browser caching does not work with ranges that don't start with zero

(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 ?

Priority: -- → P3
Whiteboard: [necko-triaged]

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

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.

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.

Severity: critical → --
Severity: -- → S3
Severity: S3 → N/A
You need to log in before you can comment on or make changes to this bug.