Changeset 1801 for draft-ietf-httpbis

Timestamp:

16/07/12 07:48:53 (10 years ago)

Author:

fielding@…

Message:

Add a paragraph about validators to security section and refer
to collision-resistant hash instead of cryptographic hash.
Addresses #365

Location:

draft-ietf-httpbis/latest

Files:

• p4-conditional.html (modified) (3 diffs)
• p4-conditional.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p4-conditional.html

@@ -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
          to a representation always results in a unique node name and revision identifier being assigned before the representation
-         is made accessible to GET. A cryptographic hash function applied to the representation data is also sufficient if the data
-         is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation
-         request is received. However, if a resource has distinct representations that differ only in their metadata, 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.
+         is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the
+         data is available prior to the response header fields being sent and the digest does not need to be recalculated every time
+         a validation request is received. However, if a resource has distinct representations that differ only in their metadata,
+         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.
       </p>
       <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
          number, perhaps combined with a variance identifier for content negotiation, to accurately differentiate between representations.
-         Other implementations might use a stored hash of representation content, a combination of various filesystem attributes, or
-         a modification timestamp that has sub-second resolution.
+         Other implementations might use a collision-resistant hash of representation content, a combination of various filesystem
+         attributes, or a modification timestamp that has sub-second resolution.
       </p>
       <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>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
       <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>.
+      </p>
+      <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
+         changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent
+         writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response
+         that is no more harmful than an HTTP exchange without conditional requests.
       </p>
       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -316 +316 @@
    based on strict revision control, wherein each change to a representation
    always results in a unique node name and revision identifier being assigned
-   before the representation is made accessible to GET.  A cryptographic hash
+   before the representation is made accessible to GET.  A collision-resistant hash
    function applied to the representation data is also sufficient if the data
    is available prior to the response header fields being sent and the digest
@@ -550 +550 @@
    combined with a variance identifier for content negotiation, to
    accurately differentiate between representations.
-   Other implementations might use a stored hash of representation content,
+   Other implementations might use a collision-resistant hash of
+   representation content,
    a combination of various filesystem attributes, or a modification
    timestamp that has sub-second resolution.
@@ -1111 +1112 @@
         <x:ref>If-Range</x:ref> are present, evaluate it:
        <list style="symbols">
-         <t>if the validator matches, respond <x:ref>206 (Partial Content)</x:ref></t>
+         <t>if the validator matches, respond 206 (Partial Content)</t>
          <t>if the validator does not match, respond <x:ref>200 (OK)</x:ref></t>
        </list>
@@ -1231 +1232 @@
    those applicable to HTTP in general &messaging;.
 </t>
+<t>
+   The validators defined by this specification are not intended to ensure
+   the validity of a representation, guard against malicious changes, or
+   detect man-in-the-middle attacks. At best, they enable more efficient cache
+   updates and optimistic concurrent writes when all participants are behaving
+   nicely. At worst, the conditions will fail and the client will receive a
+   response that is no more harmful than an HTTP exchange without conditional
+   requests.
+</t>
 </section>