Handling Partial Content / 206

[mnot]

Discussed in #97 - breaking out into a separate issue.

[mnot]

Some discussion at TPAC. There are many use cases for range requests, initial approach might be to identify bare minimum and only support those. E.g.,

1. Pass through range requests to the network
2. Serve range requests from a complete cache entry
3. Cache partial content when requested
4. Synthesise range requests to complete partial content (for full or partial requests)
5. ...

(0) and (1) are a straw-man target for now. Thoughts?

[annevk]

So from those:

1. Already happens.
2. Is something for the Cache API to decide.
3. Already happens in step 8 of https://fetch.spec.whatwg.org/#concept-http-network-fetch as far as I can tell.
4. This does not currently happen.

Here are some things I'm wondering about:

1. Should we change https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch step 15 to talk about one or more partial responses?
2. Should step 17.1 explicitly talk about a complete response?
3. Is there any freshening of headers when you get a 206 response? https://tools.ietf.org/html/rfc7234#section-4.3.4 seems to suggest there isn't. HTTP Range Requests also does not talk about this as far as I can tell.
4. Is therefore the only thing we need to introduce a 206 clause (similar to step 17 for 304) when cache mode is either "default" or "no-cache" that does recombining?

[mnot]

1. You can take the approach that every 206 is combined into one cache entry as soon as it occurs, or you can alternatively store multiple 206s and combine them at some later time. HTTP doesn't care which, as long as the effect is the same; see http://httpwg.github.io/specs/rfc7234.html#combining.responses
2. Step 14 already requires a complete response.
3. see http://httpwg.github.io/specs/rfc7233.html#combining.byte.ranges
4. maybe, yeah...

[mnot]

Is something for the Cache API to decide.

I mean the HTTP cache, not the SW cache. Or do you mean it's effectively an implementation decision?

[annevk]

I mean the HTTP cache, not the SW cache.

Ah I see. Maybe we should talk about that too.

[code-tree]

Serve range requests from a complete cache entry

Any hope that this will be implemented, in terms of being able to do it from a SW cache? It certainly would help with a problem I currently have with the Audio element and range headers

[jakearchibald]

I need to do some research to see what browsers do today vs the spec & decide if the service worker spec needs changes, or browsers need to fix bugs.

In the mean time, check out https://samdutton.github.io/samples/service-worker/prefetch-video/ - it's a bit hacky, but it works. It constructs ranged responses on the fly.

[code-tree]

Thanks for the link, the workaround worked for my audio problem too.

[jakearchibald]

So, I did the research on range requests. It's a mess. https://docs.google.com/document/d/1SphP-WNxqzZrSv_6ApC9_FpM-m_tLzm57oL3SNGg-40/edit#heading=h.1k8r6xdc6vfo

I think fetch should say something about the minimum browsers are required to support here.

[jakearchibald]

Also, unless I'm missing something, fetch should also create a network error if a 206 is returned when no range was requested.

[annevk]

@jakearchibald if you have time to work on this (or can find someone else) that would be great. I'm kinda swamped.

[jakearchibald]

I'll talk to our media teams and see what their expectations are and get as far as I can.