Changeset 1801 for draft-ietf-httpbis/latest/p4-conditional.xml

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

File:

• draft-ietf-httpbis/latest/p4-conditional.xml (modified) (4 diffs)

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>