Ignore:
Timestamp:
27/05/14 14:27:54 (6 years ago)
Author:
julian.reschke@…
Message:

updated AUTH48 version of RFC7234 (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7234-to-be.xml

    r2683 r2698  
    6767  <workgroup>HTTPbis Working Group</workgroup>
    6868
    69 
    70 
    71 <keyword>HTTP, caching</keyword>
     69  <keyword>Hypertext Transfer Protocol</keyword>
     70  <keyword>HTTP</keyword>
     71  <keyword>HTTP Caching</keyword>
    7272
    7373<abstract>
     
    345345
    346346<section anchor="constructing.responses.from.caches" title="Constructing Responses from Caches">
    347 
    348347<t>
    349348   When presented with a request, a cache MUST NOT reuse a stored response,
     
    563562      <t>If the <xref target="header.expires" format="none">Expires</xref> response header field
    564563      (<xref target="header.expires"/>) is present, use its value minus the
    565       value of the Date response header field,</t>
     564      value of the Date response header field, or</t>
    566565      <t>Otherwise, no explicit expiration time is present in the response. A
    567566      heuristic freshness lifetime might be applicable; see <xref target="heuristic.freshness"/>.</t>
     
    738737   explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    739738   directive, a "must-revalidate" cache-response-directive, or an applicable
    740    "s-maxage" or "proxy-revalidate" cache response directive; see <xref
    741    target="cache-response-directive"/>).
     739   "s-maxage" or "proxy-revalidate" cache-response-directive; see <xref target="cache-response-directive"/>).
    742740</t>
    743741<t>
     
    11861184</t>
    11871185<t>
    1188    This directive uses the token form of the argument syntax;
    1189    e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT generate
     1186   This directive uses the token form of the argument syntax:
     1187   e.g., 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate
    11901188   the quoted-string form.
    11911189</t>
     
    13931391</t>
    13941392<t>
    1395    Note: This use of the word "private" refers only to the control
    1396    of the location in which the response can be stored; the privacy of the
    1397    message content cannot be ensured. Also, private response directives with field-names are
     1393   Note: This usage of the word "private" only controls
     1394   where the response can be stored; it cannot ensure the privacy of the
     1395   message content. Also, private response directives with field-names are
    13981396   often handled by caches as if an unqualified private directive
    13991397   was received; i.e., the special handling for the qualified form is not
     
    14861484   allow the UCI community to use an otherwise private response in their
    14871485   shared cache(s) could do so by including
    1488 
    14891486</t>
    14901487<figure><artwork type="example"><![CDATA[
     
    17901787<t>
    17911788   The freshness model (<xref target="expiration.model"/>) does not
    1792    necessarily apply to history mechanisms.  That is, a history mechanism can
     1789   necessarily apply to history mechanisms. That is, a history mechanism can
    17931790   display a previous representation even if it has expired.
    17941791</t>
     
    18051802<section title="Cache Directive Registry" anchor="cache.directive.registry">
    18061803<t>
    1807    The "HTTP Cache Directive Registry" defines the name space for the
     1804   The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" defines the namespace for the
    18081805   cache directives. It has been created and is now maintained at
    18091806   &lt;http://www.iana.org/assignments/http-cache-directives&gt;.
     
    18191816</t>
    18201817<t>
    1821    Values to be added to this name space require IETF Review (see <xref target="RFC5226"/>, Section 4.1).
     1818   Values to be added to this namespace require IETF Review (see <xref target="RFC5226"/>, Section 4.1).
    18221819</t>
    18231820</section>
     
    18451842<section title="Registrations" anchor="cache.directive.registration">
    18461843<t>
    1847   The "HTTP Cache Directive Registry" shall be populated with the registrations below:
     1844  The registry has been populated with the registrations below:
    18481845</t>
    18491846
     
    19161913<section title="Warn Code Registry" anchor="warn.code.registry">
    19171914<t>
    1918    The "HTTP Warn Codes" registry defines the name space for warn codes.
     1915   The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines the namespace for warn codes.
    19191916   It has been created and is now maintained at
    19201917   &lt;http://www.iana.org/assignments/http-warn-codes&gt;.
     
    19311928</t>
    19321929<t>
    1933    Values to be added to this name pace require IETF Review (see <xref target="RFC5226"/>, Section 4.1).
     1930   Values to be added to this namespace require IETF Review (see <xref target="RFC5226"/>, Section 4.1).
    19341931</t>
    19351932</section>
     
    19371934<section title="Registrations" anchor="warn.code.registration">
    19381935<t>
    1939   The "HTTP Warn Codes" registry has been populated with the registrations below:
     1936  The registry has been populated with the registrations below:
    19401937</t>
    19411938
     
    19861983<section title="Header Field Registration" anchor="header.field.registration">
    19871984<t>
    1988    HTTP header fields are registered within the Message Header Field Registry
     1985   HTTP header fields are registered within the "Message Headers" registry
    19891986   maintained at
    1990    &lt;http://www.iana.org/assignments/message-headers&gt;.
    1991 </t>
    1992 <t>
    1993    This document defines the following HTTP header fields, so their
    1994    associated registry entries have been updated according to the permanent
    1995    registrations below (see <xref target="BCP90"/>):
     1987   &lt;http://www.iana.org/assignments/message-headers/&gt;.
     1988</t>
     1989<t>
     1990   This document defines the following HTTP header fields, so the
     1991   "Permanent Message Header Field Names" registry has been updated
     1992   accordingly (see <xref target="BCP90"/>).
    19961993</t>
    19971994
     
    20472044   More general security considerations are addressed in HTTP messaging
    20482045   <xref target="RFC7230"/> and semantics <xref target="RFC7231"/>.
    2049 
    20502046</t>
    20512047<t>
     
    23782374  clarified in several ways. In particular, it now explicitly allows
    23792375  header-specific canonicalization when processing selecting header fields.
    2380   (<xref target="caching.negotiated.responses"/>).
     2376  (<xref target="caching.negotiated.responses"/>)
    23812377</t>
    23822378<t>
     
    23982394  The "no-store" request directive doesn't apply to responses; i.e.,
    23992395  a cache can satisfy a request with no-store on it and does not invalidate
    2400   it. (<xref target="cache-request-directive.no-store"/>)
     2396  it.
     2397  (<xref target="cache-request-directive.no-store"/>)
    24012398</t>
    24022399<t>
     
    24302427<t>
    24312428  This specification introduces the Cache Directive and Warn Code Registries,
    2432   and defines considerations for new cache directives
    2433   (Sections <xref target="cache.directive.registry" format="counter"/> and <xref target="warn.code.registry" format="counter"/>).
     2429  and defines considerations for new cache directives.
     2430  (<xref target="cache.directive.registry"/> and <xref target="warn.code.registry"/>)
    24342431</t>
    24352432</section>
     
    25302527</section>
    25312528
    2532 
    2533   </back>
     2529</back>
    25342530</rfc>
Note: See TracChangeset for help on using the changeset viewer.