Changeset 861 for draft-ietf-httpbis


Ignore:
Timestamp:
22/07/10 03:10:20 (10 years ago)
Author:
fielding@…
Message:

regenerate html

Location:
draft-ietf-httpbis/latest
Files:
5 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r858 r861  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 20, 2011</td>
     436               <td class="left">Expires: January 22, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 19, 2010</td>
     489               <td class="right">July 21, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 20, 2011.</p>
     516      <p>This Internet-Draft will expire in January 22, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r857 r861  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 20, 2011</td>
     428               <td class="left">Expires: January 22, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 19, 2010</td>
     485               <td class="right">July 21, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 20, 2011.</p>
     511      <p>This Internet-Draft will expire in January 22, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    652652Accept-Encoding: gzip
    653653
    654 </pre><p id="rfc.section.2.1.p.3">In this case, the response may use the gzip Content Coding or not. If it does, it might look like that:</p>
     654</pre><p id="rfc.section.2.1.p.3">In this case, the response may or may not use the gzip content coding. If it does not, the response might look like:</p>
    655655      <div id="rfc.figure.u.5"></div>
    656656      <p>&gt;&gt; Response:</p><pre class="text">HTTP/1.1 200 OK
    … …  
    666666Hello World!
    667667Hello World!
    668 </span></pre><p id="rfc.section.2.1.p.5">A variant that does use gzip Content Coding would be:</p>
     668</span></pre><p id="rfc.section.2.1.p.5">An alternative representation that does use gzip content coding would be:</p>
    669669      <div id="rfc.figure.u.6"></div>
    670670      <p>&gt;&gt; Response:</p><pre class="text">HTTP/1.1 200 OK
    … …  
    677677
    678678<em>...binary data...</em></pre><div class="note" id="rfc.section.2.1.p.7">
    679          <p> <b>Note:</b> Content Codings are a property of the response entity, thus affect the Entity Tag. An alternative are Transfer Codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) which apply only to the transfer of the message, and thus do not require assigning distinct entity tags.
     679         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity tag of an encoded representation must be distinct
     680            from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
     681            (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity tags.
    680682         </p>
    681683      </div>
    … …  
    686688      <p id="rfc.section.3.1.p.1">If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server <em class="bcp14">SHOULD</em> respond with this status code. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    687689      </p>
    688       <p id="rfc.section.3.1.p.2">The response <em class="bcp14">MUST</em> include the following header fields:
    689       </p>
    690       <ul>
    691          <li>
    692             <p>Date, unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    693             </p>
    694             <p>If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without
    695                one (as already specified by <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, caches will operate correctly.
    696             </p>
    697          </li>
    698          <li>
    699             <p>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request.</p>
    700          </li>
    701          <li>
    702             <p>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
    703                variant.
    704             </p>
    705          </li>
    706       </ul>
    707       <p id="rfc.section.3.1.p.3">If the conditional GET used a strong cache validator (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
    708       </p>
    709       <p id="rfc.section.3.1.p.4">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional.
     690      <p id="rfc.section.3.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. If a 200 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag,
     691         Expires, Last-Modified, or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
     692      </p>
     693      <p id="rfc.section.3.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
     694         the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
     695         cache updates (e.g., future HTTP extensions).
     696      </p>
     697      <p id="rfc.section.3.1.p.4">If a 304 response includes an entity-tag that indicates a representation not currently cached, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If that conditional request originated with an outbound client, such as a user agent
     698         with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MUST</em> be forwarded to the outbound client. Otherwise, disregard the response and repeat the request without the conditional.
    710699      </p>
    711700      <p id="rfc.section.3.1.p.5">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response.
    … …  
    908897      <div id="rfc.iref.h.1"></div>
    909898      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    910       <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for the requested variant, which may be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
     899      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for one representation of the resource identified by the Effective Request URI. An entity tag is intended for use as a resource-local
     900         identifier for differentiating between representations of the same resource that vary over time or via content negotiation
     901         (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    911902      </p>
    912903      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#header.etag" class="smpl">ETag</a>   = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a>
    … …  
    916907  ETag: W/"xyzzy"
    917908  ETag: ""
    918 </pre><p id="rfc.section.6.1.p.4">The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable
    919          validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date
    920          values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification
    921          dates.
     909</pre><p id="rfc.section.6.1.p.4">An entity tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations
     910         where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient,
     911         or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.
    922912      </p>
    923913      <p id="rfc.section.6.1.p.5">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an
    … …  
    964954      <div id="rfc.iref.h.3"></div>
    965955      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    966       <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional: if the requested variant has not
    967          been modified since the time specified in this field, the server will not return an entity; instead, a 304 (Not Modified)
    968          response will be returned.
     956      <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional by date: if the representation that
     957         would have been transferred in a 200 response to a GET request has not been modified since the time specified in this field,
     958         then do not perform the method; instead, respond as detailed below.
    969959      </p>
    970960      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>   = "If-Modified-Since" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    973963</pre><p id="rfc.section.6.3.p.3">An example of the field is:</p>
    974964      <div id="rfc.figure.u.12"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    975 </pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header and no Range header requests that the identified entity be transferred only
    976          if it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes
    977          the following cases:
     965</pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header and no Range header requests that the representation be transferred only if
     966         it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the
     967         following cases:
    978968      </p>
    979969      <ol>
    … …  
    981971            invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid.
    982972         </li>
    983          <li>If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET.</li>
    984          <li>If the variant has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified) response.
     973         <li>If the representation has been modified since the If-Modified-Since date, the response is exactly the same as for a normal
     974            GET.
     975         </li>
     976         <li>If the representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified) response.
    985977         </li>
    986978      </ol>
    … …  
    10471039      <div id="rfc.iref.h.5"></div>
    10481040      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    1049       <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the requested resource has
    1050          not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
    1051       </p>
    1052       <p id="rfc.section.6.5.p.2">If the requested variant has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).
     1041      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the representation that would
     1042         have been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified
     1043         in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
     1044      </p>
     1045      <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).
    10531046      </p>
    10541047      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>   = "If-Unmodified-Since" ":" <a href="#core.rules" class="smpl">OWS</a>
    … …  
    10671060      <div id="rfc.iref.h.6"></div>
    10681061      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2>
    1069       <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the variant was last
    1070          modified.
     1062      <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the representation
     1063         was last modified.
    10711064      </p>
    10721065      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a>   = "Last-Modified" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.last-modified" class="smpl">Last-Modified-v</a>
    … …  
    10891082      </p>
    10901083      <p id="rfc.section.6.6.p.9">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered
    1091          to be valid if the entity has not been modified since the Last-Modified value.
     1084         to be valid if the representation has not been modified since the Last-Modified value.
    10921085      </p>
    10931086      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    … …  
    14421435                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.5">1.2.2</a></li>
    14431436                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">2.1</a></li>
    1444                         <li class="indline1"><em>Section 9.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">3.1</a></li>
    1445                         <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">3.1</a></li>
     1437                        <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">3.1</a></li>
     1438                        <li class="indline1"><em>Section 9.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">3.1</a></li>
    14461439                     </ul>
    14471440                  </li>

  • draft-ietf-httpbis/latest/p5-range.html

    r859 r861  
    656656         </li>
    657657         <li>Date</li>
    658          <li>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</li>
    659          <li>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
    660             variant
     658         <li>Cache-Control, ETag, Expires, Content-Location, Last-Modified, and/or Vary, if the header field would have been sent in a
     659            200 response to the same request
    661660         </li>
    662661      </ul>

  • draft-ietf-httpbis/latest/p6-cache.html

    r857 r861  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 20, 2011</td>
     430               <td class="left">Expires: January 22, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 19, 2010</td>
     491               <td class="right">July 21, 2010</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire in January 20, 2011.</p>
     517      <p>This Internet-Draft will expire in January 22, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r857 r861  
    394394      <meta name="dct.creator" content="Reschke, J. F.">
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    398398      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    425425            </tr>
    426426            <tr>
    427                <td class="left">Expires: January 20, 2011</td>
     427               <td class="left">Expires: January 22, 2011</td>
    428428               <td class="right">HP</td>
    429429            </tr>
    … …  
    478478            <tr>
    479479               <td class="left"></td>
    480                <td class="right">July 19, 2010</td>
     480               <td class="right">July 21, 2010</td>
    481481            </tr>
    482482         </tbody>
    … …  
    504504         in progress”.
    505505      </p>
    506       <p>This Internet-Draft will expire in January 20, 2011.</p>
     506      <p>This Internet-Draft will expire in January 22, 2011.</p>
    507507      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    508508      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.