Ignore:
Timestamp:
Jul 16, 2012, 12:48:53 AM (7 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:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1800 r1801  
    316316   based on strict revision control, wherein each change to a representation
    317317   always results in a unique node name and revision identifier being assigned
    318    before the representation is made accessible to GET.  A cryptographic hash
     318   before the representation is made accessible to GET.  A collision-resistant hash
    319319   function applied to the representation data is also sufficient if the data
    320320   is available prior to the response header fields being sent and the digest
     
    550550   combined with a variance identifier for content negotiation, to
    551551   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,
    553554   a combination of various filesystem attributes, or a modification
    554555   timestamp that has sub-second resolution.
     
    11111112        <x:ref>If-Range</x:ref> are present, evaluate it:
    11121113       <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>
    11141115         <t>if the validator does not match, respond <x:ref>200 (OK)</x:ref></t>
    11151116       </list>
     
    12311232   those applicable to HTTP in general &messaging;.
    12321233</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>
    12331243</section>
    12341244
Note: See TracChangeset for help on using the changeset viewer.