Changeset 1801 for draft-ietf-httpbis
- Timestamp:
- 16/07/12 07:48:53 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1800 r1801 711 711 <p id="rfc.section.2.1.p.5">There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change 712 712 to a representation always results in a unique node name and revision identifier being assigned before the representation 713 is made accessible to GET. A c ryptographic hash function applied to the representation data is also sufficient if the data714 is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation715 request is received. However, if a resource has distinct representations that differ only in their metadata, such as might716 occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior.713 is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the 714 data is available prior to the response header fields being sent and the digest does not need to be recalculated every time 715 a validation request is received. However, if a resource has distinct representations that differ only in their metadata, 716 such as might occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations and avoid confusing cache behavior. 717 717 </p> 718 718 <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is a representation metadata value that might not be changed for every change to the representation … … 833 833 <p id="rfc.section.2.3.1.p.2">For example, a resource that has implementation-specific versioning applied to all changes might use an internal revision 834 834 number, perhaps combined with a variance identifier for content negotiation, to accurately differentiate between representations. 835 Other implementations might use a stored hash of representation content, a combination of various filesystem attributes, or836 a modification timestamp that has sub-second resolution.835 Other implementations might use a collision-resistant hash of representation content, a combination of various filesystem 836 attributes, or a modification timestamp that has sub-second resolution. 837 837 </p> 838 838 <p id="rfc.section.2.3.1.p.3">Origin servers <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since … … 1259 1259 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1260 1260 <p id="rfc.section.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1261 </p> 1262 <p id="rfc.section.7.p.2">The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious 1263 changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent 1264 writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response 1265 that is no more harmful than an HTTP exchange without conditional requests. 1261 1266 </p> 1262 1267 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1800 r1801 316 316 based on strict revision control, wherein each change to a representation 317 317 always results in a unique node name and revision identifier being assigned 318 before the representation is made accessible to GET. A c ryptographichash318 before the representation is made accessible to GET. A collision-resistant hash 319 319 function applied to the representation data is also sufficient if the data 320 320 is available prior to the response header fields being sent and the digest … … 550 550 combined with a variance identifier for content negotiation, to 551 551 accurately differentiate between representations. 552 Other implementations might use a stored hash of representation content, 552 Other implementations might use a collision-resistant hash of 553 representation content, 553 554 a combination of various filesystem attributes, or a modification 554 555 timestamp that has sub-second resolution. … … 1111 1112 <x:ref>If-Range</x:ref> are present, evaluate it: 1112 1113 <list style="symbols"> 1113 <t>if the validator matches, respond <x:ref>206 (Partial Content)</x:ref></t>1114 <t>if the validator matches, respond 206 (Partial Content)</t> 1114 1115 <t>if the validator does not match, respond <x:ref>200 (OK)</x:ref></t> 1115 1116 </list> … … 1231 1232 those applicable to HTTP in general &messaging;. 1232 1233 </t> 1234 <t> 1235 The validators defined by this specification are not intended to ensure 1236 the validity of a representation, guard against malicious changes, or 1237 detect man-in-the-middle attacks. At best, they enable more efficient cache 1238 updates and optimistic concurrent writes when all participants are behaving 1239 nicely. At worst, the conditions will fail and the client will receive a 1240 response that is no more harmful than an HTTP exchange without conditional 1241 requests. 1242 </t> 1233 1243 </section> 1234 1244
Note: See TracChangeset
for help on using the changeset viewer.