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

cache.match should create partial responses if given a range request #913

Open
jakearchibald opened this Issue Jun 15, 2016 · 11 comments

Comments

Projects
None yet
6 participants
@jakearchibald
Copy link
Collaborator

jakearchibald commented Jun 15, 2016

I did some research on range requests, and everything's inconsistent https://docs.google.com/document/d/1SphP-WNxqzZrSv_6ApC9_FpM-m_tLzm57oL3SNGg-40/edit#heading=h.1k8r6xdc6vfo

The only reliable way of streaming video across browsers is for the server to return exactly the range requested. It feels like it's expected, and faster, for cache.match(request) to generate a 206 (or 416) if the request has a range header.

It'd be great to do this for opaque responses too, where the generated 206/416 would also be opaque, but I'd like a security person to weigh in there.

@wanderview

This comment has been minimized.

Copy link
Member

wanderview commented Jun 15, 2016

What about on the put() side? If the server is providing partials, does cache have to stitch them back together for a cache.match() without a range header?

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jun 16, 2016

I think we should reject putting 206s for now, but it's something we could look at in version n+1.

@ylafon

This comment has been minimized.

Copy link
Member

ylafon commented Jun 16, 2016

ranged put should be avoided, patch would be far much better.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jun 16, 2016

@ylafon we're talking about the cache APIs put method, not the HTTP verb.

@ylafon

This comment has been minimized.

Copy link
Member

ylafon commented Jun 16, 2016

Reading 'put' in the context of ranges triggers pavlovian reactions... Sorry for the noise.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jun 17, 2016

It'd be great to do this for opaque responses too

Hmm, I'm not sure this is a good idea. Imagine a file containing

blahblahblahblah('secret-data')blahblahblah

I could request bytes=0-31 and serve it in response to a <script src>, and get "secret-data".

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jul 29, 2016

F2F:

  • Browsers should fix themselves to work with 200 responses sensibly
  • So making the change in this issue isn't urgent
@mkruisselbrink

This comment has been minimized.

Copy link
Collaborator

mkruisselbrink commented Aug 17, 2016

For what it's worth, it seems blink might start issuing range requests for tags in some situations at some point (https://groups.google.com/a/chromium.org/d/msg/blink-dev/pOTcSsMsAuo/YFiYRy7fAwAJ), but at least the design doc sounds like just replying with 200 responses to these requests should still work, so this shouldn't really change anything from the SW side of things I believe.

@inexorabletash

This comment has been minimized.

Copy link
Member

inexorabletash commented Aug 28, 2017

Someone raised this on the Chromium bug tracker:

https://bugs.chromium.org/p/chromium/issues/detail?id=759630

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Aug 29, 2017

I've started some of the related work around this, eg whatwg/fetch#560 and whatwg/html#2814.

@mattto

This comment has been minimized.

Copy link
Member

mattto commented Oct 26, 2018

F2F: Spec returning 206 from Cache Storage for range requests (likely making it a MAY to match http). Also, look into what sites are doing to see whether it would break things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment