Skip to content
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

Added description of caching limitations for Range-less shift-buffer requests #506

Merged
merged 3 commits into from Mar 19, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
16 changes: 15 additions & 1 deletion draft-ietf-httpbis-rand-access-live.xml
Expand Up @@ -4,6 +4,7 @@
<!ENTITY RFC5234 SYSTEM "http://www.rfc-editor.org/refs/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC7230 SYSTEM "http://www.rfc-editor.org/refs/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7233 SYSTEM "http://www.rfc-editor.org/refs/bibxml/reference.RFC.7233.xml">
<!ENTITY RFC7234 SYSTEM "http://www.rfc-editor.org/refs/bibxml/reference.RFC.7234.xml">
<!ENTITY RFC8216 SYSTEM "http://www.rfc-editor.org/refs/bibxml/reference.RFC.8216.xml">

<!-- Fudge for XMLmind which doesn't have this built in -->
Expand Down Expand Up @@ -389,7 +390,7 @@ Content-Range: bytes 1234567-999999999999/*
</section>
<section anchor="shift-buffers" title="Shift Buffer Representations">
<t>
Some representations lend themselves to front-end content deletion in addition to aggregation. While still supporting random access, representations of this type have a portion at the beginning (the "0" end) of the randomly-accessible region that become inaccessible over time. Examples of this kind of representation would be an audio-video time-shift buffer or a rolling log file.
Some representations lend themselves to front-end content removal in addition to aggregation. While still supporting random access, representations of this type have a portion at the beginning (the "0" end) of the randomly-accessible region that become inaccessible over time. Examples of this kind of representation would be an audio-video time-shift buffer or a rolling log file.
</t>
<t>
For example a Range request containing:
Expand Down Expand Up @@ -463,6 +464,18 @@ Content-Range: bytes 1020000-1254567/*
<t>
from the server to indicate that the response will start at byte 1020000, end at byte 1254567, and will not include any aggregated content. This is the response expected from a typical HTTP server - one that doesn't support byte-range requests on aggregating content.
</t>
<t>
Note that responses to GET requests against shift-buffer representations using Range
can be cached by intermediaries, since the Content-Range response header indicates
which portion of the representation is being returned in the response body. However
GET requests without a Range header cannot be cached since the first byte of the response
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

either that or the resource provided might be identified differently

that is, if the start of /live moves by 10M, then you might redirect to /live+10M, all assuming that the redirect works (content-location isn't especially nice for this because it isn't any more cacheable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting idea @martinthomson. I'll see if I can reword to not preclude this option.

So guess I need to sprinkle in "successful responses" on both of these sentences and maybe include redirect as an example.

I'll revise tonight. Thx!

body can vary from request to request. To ensure Range-less GET requests against
shift-buffer representations are not cached, servers hosting a shift-buffer
representation should either not return a 200-level response (e.g. sending a
300-level redirect response with a URI that represents the current start of the
shift-buffer) or indicate the response is non-cacheable. See HTTP Caching
(<xref target="RFC7234"/>) for details on HTTP cache control.
</t>
</section>
</section>

Expand All @@ -484,6 +497,7 @@ Content-Range: bytes 1020000-1254567/*
&RFC2119;
&RFC7230;
&RFC7233;
&RFC7234;
</references>

<references title="Informative References">
Expand Down