Ignore:
Timestamp:
02/09/11 06:49:28 (12 years ago)
Author:
julian.reschke@…
Message:

regen HTML

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1432 r1434  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 4, 2012";
     361       content: "Expires March 5, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    441441            </tr>
    442442            <tr>
    443                <td class="left">Expires: March 4, 2012</td>
     443               <td class="left">Expires: March 5, 2012</td>
    444444               <td class="right">HP</td>
    445445            </tr>
    … …  
    494494            <tr>
    495495               <td class="left"></td>
    496                <td class="right">September 1, 2011</td>
     496               <td class="right">September 2, 2011</td>
    497497            </tr>
    498498         </tbody>
    … …  
    527527         in progress”.
    528528      </p>
    529       <p>This Internet-Draft will expire on March 4, 2012.</p>
     529      <p>This Internet-Draft will expire on March 5, 2012.</p>
    530530      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    531531      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r1430 r1434  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 4, 2012";
     361       content: "Expires March 5, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    439439            </tr>
    440440            <tr>
    441                <td class="left">Expires: March 4, 2012</td>
     441               <td class="left">Expires: March 5, 2012</td>
    442442               <td class="right">HP</td>
    443443            </tr>
    … …  
    492492            <tr>
    493493               <td class="left"></td>
    494                <td class="right">September 1, 2011</td>
     494               <td class="right">September 2, 2011</td>
    495495            </tr>
    496496         </tbody>
    … …  
    522522         in progress”.
    523523      </p>
    524       <p>This Internet-Draft will expire on March 4, 2012.</p>
     524      <p>This Internet-Draft will expire on March 5, 2012.</p>
    525525      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    526526      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    15351535         forwarding of packets until the connection is closed.
    15361536      </p>
    1537       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 4.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1537      <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    15381538         For example,
    15391539      </p>
    … …  
    33253325                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">7.5.6</a></li>
    33263326                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li>
     3327                        <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.9</a></li>
    33273328                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">8.8</a>, <a href="#rfc.xref.Part1.42">8.9</a></li>
    33283329                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li>
    33293330                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>
    3330                         <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.9</a></li>
    33313331                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
    33323332                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a></li>

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

    r1426 r1434  
    359359  }
    360360  @bottom-center {
    361        content: "Expires March 4, 2012";
     361       content: "Expires March 5, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    430430            </tr>
    431431            <tr>
    432                <td class="left">Expires: March 4, 2012</td>
     432               <td class="left">Expires: March 5, 2012</td>
    433433               <td class="right">J. Mogul</td>
    434434            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">September 1, 2011</td>
     489               <td class="right">September 2, 2011</td>
    490490            </tr>
    491491         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on March 4, 2012.</p>
     519      <p>This Internet-Draft will expire on March 5, 2012.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r1426 r1434  
    362362  }
    363363  @bottom-center {
    364        content: "Expires March 4, 2012";
     364       content: "Expires March 5, 2012";
    365365  }
    366366  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-09-01">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-09-02">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: March 4, 2012</td>
     436               <td class="left">Expires: March 5, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">September 1, 2011</td>
     497               <td class="right">September 2, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    525525         in progress”.
    526526      </p>
    527       <p>This Internet-Draft will expire on March 4, 2012.</p>
     527      <p>This Internet-Draft will expire on March 5, 2012.</p>
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    756756      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    757757</pre><p id="rfc.section.1.5.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
    758          its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
     758         its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
    759759      </p>
    760760      <div id="rfc.iref.c.4"></div>
    … …  
    901901         is not already present.
    902902      </p>
    903       <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this
    904          fraction might be 10%.
     903      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     904         time. A typical setting of this fraction might be 10%.
    905905      </p>
    906906      <div class="note" id="rfc.section.2.3.1.1.p.4">
    … …  
    989989         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
    990990      </p>
    991       <p id="rfc.section.2.3.3.p.3">A cache <em class="bcp14">SHOULD NOT</em> return stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
     991      <p id="rfc.section.2.3.3.p.3">A cache <em class="bcp14">MUST NOT</em> return stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
    992992         or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    993993      </p>
    … …  
    995995      </p>
    996996      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
    997          forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
    998          A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
     997         forward to the requesting client, and the received response is no longer fresh, the cache can forward it to the requesting
     998         client without adding a new Warning (but without removing any existing Warning header fields). A cache shouldn't attempt to
     999         validate a response simply because that response became stale in transit.
    9991000      </p>
    10001001      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    … …  
    10031004         update it. This process is known as "validating" or "revalidating" the stored response.
    10041005      </p>
    1005       <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
    1006       </p>
    1007       <p id="rfc.section.2.4.p.3">Additionally, a cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
    1008          URI, if present. However, if any of the stored responses contains only partial content, the cache <em class="bcp14">SHOULD NOT</em> include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by
    1009          that stored response.
     1006      <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an If-Modified-Since header field whose value is that of the Last-Modified
     1007         header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
     1008      </p>
     1009      <p id="rfc.section.2.4.p.3">Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses
     1010         stored for the requested URI, if present. However, if any of the stored responses contains only partial content, the cache
     1011         shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied
     1012         by that stored response.
    10101013      </p>
    10111014      <p id="rfc.section.2.4.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
    … …  
    10151018         </li>
    10161019         <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    1017             request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
    1018          </li>
    1019          <li>However, if a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
     1020            request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
     1021         </li>
     1022         <li>However, if a cache receives a 5xx response while attempting to validate a response, it can either forward this response to
     1023            the requesting client, or act as if the server failed to respond. In the latter case, it can return a previously stored response
     1024            (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    10201025         </li>
    10211026      </ul>
    … …  
    10571062         in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    10581063      </p>
    1059       <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
     1064      <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
    10601065      </p>
    10611066      <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all
    … …  
    10991104      <p id="rfc.section.2.7.p.6">If multiple selected responses are available, the most recent response (as determined by the Date header field) is used; see <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;2.2</a>.
    11001105      </p>
    1101       <p id="rfc.section.2.7.p.7">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
     1106      <p id="rfc.section.2.7.p.7">If no selected response is available, the cache can forward the presented request to the origin server in a conditional request;
     1107         see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    11021108      </p>
    11031109      <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2>
    … …  
    12851291            a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
    12861292         </li>
    1287          <li>A server <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
    1288             operation, such as a silently unexecuted financial transaction.
     1293         <li>The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation
     1294            could result in incorrect operation, such as a silently unexecuted financial transaction.
    12891295         </li>
    12901296      </ul>
    … …  
    13921398</pre><p id="rfc.section.3.4.p.4">When the Cache-Control header is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    13931399      </p>
    1394       <p id="rfc.section.3.4.p.5">When sending a no-cache request, a client <em class="bcp14">SHOULD</em> include both pragma and cache-control directives unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control
    1395          response directives at HTTP/1.1 caches. For example:
     1400      <p id="rfc.section.3.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
     1401         no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
    13961402      </p>
    13971403      <div id="rfc.figure.u.16"></div> <pre class="text">GET / HTTP/1.1
    … …  
    14611467      <p id="rfc.section.3.6.p.6">When this occurs, the user agent <em class="bcp14">SHOULD</em> inform the user of as many of them as possible, in the order that they appear in the response.
    14621468      </p>
    1463       <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header fields <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning header fields <em class="bcp14">SHOULD</em> be added after any existing Warning headers fields.
     1469      <p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New
     1470         Warning header fields are added after any existing Warning headers fields.
    14641471      </p>
    14651472      <p id="rfc.section.3.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
    … …  
    14961503      <p id="rfc.section.3.6.p.14"> 112 Disconnected operation </p>
    14971504      <ul class="empty">
    1498          <li>A cache <em class="bcp14">SHOULD</em> b include this if it is intentionally disconnected from the rest of the network for a period of time.
     1505         <li>A cache <em class="bcp14">SHOULD</em> include this if it is intentionally disconnected from the rest of the network for a period of time.
    14991506         </li>
    15001507      </ul>
Note: See TracChangeset for help on using the changeset viewer.