-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-mcmanus-immutable-01.xml
199 lines (139 loc) · 7.12 KB
/
draft-mcmanus-immutable-01.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml">
<!ENTITY RFC7232 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7232.xml">
<!ENTITY RFC7234 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml">
]>
<rfc ipr="trust200902" docName="draft-mcmanus-immutable-01" category="std">
<front>
<title abbrev="I-D">HTTP Immutable Responses</title>
<author initials="P." surname="McManus" fullname="Patrick McManus">
<organization>Mozilla</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2016" month="December" day="19"/>
<abstract>
<t>The immutable HTTP response Cache-Control extension allows servers to
identify resources that will not be updated during their freshness
lifetime. This assures that a client never needs to revalidate a
cached fresh resource to be certain it has not been modified.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The HTTP freshness lifetime <xref target="RFC7234"></xref> caching attribute
specifies that a client may safely reuse a response to satisfy future
requests over a specific period of time. It does not specify that the
resource will be not be modified during that period.</t>
<t>For instance, a front page newspaper photo with a freshness lifetime
of one hour would mean that no user should see a photo more than one
hour old. However, the photo could be updated at any time resulting in
different users seeing different photos depending on the contents of
their caches for up to one hour. This is compliant with the caching
mechanism defined in <xref target="RFC7234"></xref>.</t>
<t>Users that need to confirm there have been no updates to their current
cached resources typically invoke the reload (or refresh) mechanism in
the user agent. This in turn generates a conditional request <xref target="RFC7232"></xref>
and either a new representation or, if unmodified, a 304 response
<xref target="RFC7231"></xref> is returned. A user agent that manages HTML and its
dependent sub-resources may issue hundreds of conditional requests to
refresh all portions of a common HTML page <xref target="REQPERPAGE"></xref>.</t>
<t>Through the use of the versioned URL design pattern some content
providers never create more than one variant of a sub-resource. When
these resources need an update they are simply published under a new URL,
typically embedding a variant identifier in the path, and references
to the sub-resource are updated with the new path information.</t>
<t>For example, https://www.example.com/101016/main.css might be updated
and republished as https://www.example.com/102026/main.css and the html that
references it is changed at the same time. This design pattern allows
a very large freshness lifetime to be applied to the sub-resource
without guessing when it will be updated in the future.</t>
<t>Unfortunately, the user-agent is not aware of the versioned URL design
pattern. User driven refresh events still translate into wasted
conditional requests for each sub-resource as each will return 304
responses.</t>
<t>The immutable HTTP response Cache-Control extension allows servers to
identify resources that will not be updated during their freshness
lifetime. This effectively instructs the client that any conditional
request for a previously served variant of that resource may be safely
skipped without worrying that it has been updated.</t>
</section>
<section anchor="the-immutable-cache-control-extension" title="The immutable Cache-Control extension">
<t>When present in an HTTP response, the immutable Cache-Control
extension indicates that the origin server MUST NOT update the representation
of that resource during the freshness lifetime of the response.</t>
<t>The immutable extension only applies during the freshness lifetime of
the response. Stale responses SHOULD be revalidated as they normally
would be in the absence of immutable.</t>
<t>The immutable extension takes no arguments and if any arguments are
present they have no meaning. Multiple instances of the immutable
extension are equivalent to one instance. The presence of an immutable
Cache-Control extension in a request has no effect.</t>
<section anchor="about-intermediaries" title="About Intermediaries">
<t>An immutable response has the same semantic meaning for proxy clients
as it does for User-Agent based clients and they therefore MAY also
presume a conditional revalidation for a response marked immutable
would return 304. A proxy client who uses immutable to anticipate a
304 response may choose whether to reply with a 304 or 200 to its
requesting client.</t>
</section>
<section anchor="example" title="Example">
<t>Cache-Control: max-age=31536000, immutable</t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The immutable mechanism acts as form of soft pinning and, as with all
pinning mechanisms, creates a vector for amplification of cache
corruption incidents. These incidents include cache poisoning
attacks. Three mechanisms are suggested for mitigation of this risk:</t>
<t><list style="symbols">
<t>Clients should ignore immutable for resources that are not
part of an authenticated context such as HTTPS. Authenticated resources are less
vulnerable to cache poisoning.</t>
<t>User-Agents often provide two different refresh mechanismss: reload
and some form of force-reload. The latter is used to rectify
interrupted loads and other corruption. These reloads, typically
indicated through no-cache request attributes, should ignore
immutable as well.</t>
<t>Clients should ignore immutable for resources that do not provide a
strong indication that the stored response size is the correct
response size such as responses delimited by connection close.</t>
</list></t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t><xref target="RFC7234"></xref> sections 7.1 and 7.1.2 require registration of the
immutable extension in the “Hypertext Transfer Protocol (HTTP) Cache
Directive Registry” with IETF Review.</t>
<t><list style="symbols">
<t>Cache-Directive: immutable</t>
<t>Pointer to specification text: [this document]</t>
</list></t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>Thank you to Ben Maurer for partnership in developing and testing this
idea. Thank you to Amos Jeffries for help with proxy interactions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC7231;
&RFC7232;
&RFC7234;
</references>
<references title='Informative References'>
<reference anchor="REQPERPAGE" target="http://httparchive.org/interesting.php#reqTotal">
<front>
<title>HTTP Archive</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
</references>
</back>
</rfc>