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

Even HTTP/1.0 caches now support Age and CC #667

Merged
merged 5 commits into from
Jan 11, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 8 additions & 18 deletions draft-ietf-httpbis-cache-latest.xml
Original file line number Diff line number Diff line change
Expand Up @@ -872,17 +872,14 @@
corrected_age_value = age_value + response_delay;
</artwork>
<t>
These are combined as
The corrected_age_value &MAY; be used as the corrected_initial_age. In
circumstances where very old cache implementations that might not correctly
insert <x:ref>Age</x:ref> are present, corrected_initial_age can be calculated
more conservatively as
</t>
<artwork type="code">
corrected_initial_age = max(apparent_age, corrected_age_value);
</artwork>
<t>
unless the cache is confident in the value of the <x:ref>Age</x:ref> header
field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
header field), in which case the corrected_age_value &MAY; be used as the
corrected_initial_age.
</t>
<t>
The current_age of a stored response can then be calculated by adding the
time (in seconds) since the stored response was last validated by
Expand Down Expand Up @@ -1241,9 +1238,7 @@
<t>
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request. However,
lack of an Age header field does not imply the origin was contacted, since
the response might have been received from an HTTP/1.0 cache that does not
implement Age.
lack of an Age header field does not imply the origin was contacted.
</t>
</section>

Expand All @@ -1262,11 +1257,6 @@
See <xref target="cache.control.extensions"/> for information about how
Cache-Control directives defined elsewhere are handled.
</t>
<aside>
<t>
&Note; Some HTTP/1.0 caches might not implement Cache-Control.
</t>
</aside>
<t>
A proxy, whether or not it implements a cache, &MUST; pass cache directives
through in forwarded messages, regardless of their
Expand Down Expand Up @@ -1512,8 +1502,7 @@
to be needed for single-entry lists).
</t>
<aside><t>
&Note; Although it has been back-ported to many implementations, some
HTTP/1.0 caches will not recognize or obey this directive. Also, the
&Note; The
qualified form of the directive is often handled by caches as if an
unqualified no-cache directive was received; i.e., the special handling
for the qualified form is not widely implemented.
Expand Down Expand Up @@ -2537,9 +2526,10 @@
<section title="Since draft-ietf-httpbis-cache-13" anchor="changes.since.13">
<ul x:when-empty="None yet.">
<li>In <xref target="cache-response-directive.must-revalidate"/>, clarify requirements around generating an error response (<eref target="https://github.com/httpwg/http-core/issues/608"/>)</li>
<li>Changed to using "content" instead of "payload" or "payload data" to avoid confusion with the payload of version-specific messaging frames (<eref target="https://github.com/httpwg/http-core/issues/654"/>)</li>
<li>In <xref target="freshening.responses"/>, clarify how multiple validators are handled (<eref target="https://github.com/httpwg/http-core/issues/659"/>)</li>
<li>In <xref target="age.calculations"/>, <xref target="field.cache-control"/>, and <xref target="cache-response-directive.no-cache"/>, remove notes about very old HTTP/1.0 behaviours (<eref target="https://github.com/httpwg/http-core/issues/660"/>)</li>
<li>In <xref target="cache-response-directive.must-understand"/>, modify operation to be more backwards-compatible with existing implementations (<eref target="https://github.com/httpwg/http-core/issues/661"/>)</li>
<li>Changed to using "content" instead of "payload" or "payload data" to avoid confusion with the payload of version-specific messaging frames (<eref target="https://github.com/httpwg/http-core/issues/654"/>)</li>
</ul>
</section>
</section>
Expand Down