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.html

    r1800 r1801  
    711711      <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
    712712         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 cryptographic hash function applied to the representation data is also sufficient if the data
    714          is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation
    715          request is received. However, if a resource has distinct representations that differ only in their metadata, such as might
    716          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.
    717717      </p>
    718718      <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
     
    833833      <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
    834834         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, or
    836          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.
    837837      </p>
    838838      <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
     
    12591259      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    12601260      <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.
    12611266      </p>
    12621267      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
Note: See TracChangeset for help on using the changeset viewer.