Ignore:
Timestamp:
Mar 28, 2012, 4:29:44 AM (7 years ago)
Author:
julian.reschke@…
Message:

fix broken inter-document links, regen HTML

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1617 r1625  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 27, 2012";
     462       content: "Expires September 29, 2012";
    463463  }
    464464  @bottom-right {
     
    502502      <meta name="dct.creator" content="Reschke, J. F.">
    503503      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    504       <meta name="dct.issued" scheme="ISO8601" content="2012-03-26">
     504      <meta name="dct.issued" scheme="ISO8601" content="2012-03-28">
    505505      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    506506      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    534534            </tr>
    535535            <tr>
    536                <td class="left">Expires: September 27, 2012</td>
     536               <td class="left">Expires: September 29, 2012</td>
    537537               <td class="right">greenbytes</td>
    538538            </tr>
    539539            <tr>
    540540               <td class="left"></td>
    541                <td class="right">March 26, 2012</td>
     541               <td class="right">March 28, 2012</td>
    542542            </tr>
    543543         </tbody>
     
    572572         in progress”.
    573573      </p>
    574       <p>This Internet-Draft will expire on September 27, 2012.</p>
     574      <p>This Internet-Draft will expire on September 29, 2012.</p>
    575575      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    576576      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    910910         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    911911         that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    912          a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
     912         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    913913      </p>
    914914      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
     
    11741174      </div>
    11751175      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1176 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#method" title="Method">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1176</pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    11771177      </p>
    11781178      <div id="rfc.iref.r.6"></div>
     
    11891189      <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    11901190         it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a 501 (Not Implemented) status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1191          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1191         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    11921192      </p>
    11931193      <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
     
    12231223                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12241224</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1225          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1225         the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12261226      </p>
    12271227      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
     
    18261826      </p>
    18271827      <div id="authority-form">
    1828          <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
     1828         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
    18291829         </p>
    18301830      </div>
    18311831      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    18321832</pre><div id="asterisk-form">
    1833          <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1833         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    18341834            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    18351835         </p>
     
    19921992         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19931993         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
    1994          see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
     1994         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
    19951995      </p>
    19961996      <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response.
     
    21372137      <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
    21382138      </p>
    2139       <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2139      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    21402140         send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
    21412141      </p>
     
    21672167      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    21682168      <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2169          sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 6.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
     2169         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
    21702170         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
    21712171      </p>
     
    21802180      </p>
    21812181      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2182       <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2182      <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21832183         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21842184         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     
    21872187      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21882188      <ul>
    2189          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2190          </li>
    2191          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     2189         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2190         </li>
     2191         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    21922192         </li>
    21932193      </ul>
     
    22332233         <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    22342234            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2235             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2235            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22362236         </li>
    22372237      </ul>
     
    22702270      </p>
    22712271      <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2272          is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2272         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22732273      </p>
    22742274      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
     
    26942694         that most implementations will choose substantially higher limits.
    26952695      </p>
    2696       <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.4.12</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2696      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    26972697      </p>
    26982698      <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
     
    37523752                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a>, <a href="#rfc.xref.Part2.14">6.4.3</a>, <a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a>, <a href="#rfc.xref.Part2.17">6.4.3</a>, <a href="#rfc.xref.Part2.18">6.5</a>, <a href="#rfc.xref.Part2.19">8.6</a>, <a href="#rfc.xref.Part2.20">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    37533753                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">3.1.1</a></li>
     3754                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a></li>
     3755                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.3</a></li>
     3756                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    37543757                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    37553758                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a></li>
    3756                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a></li>
    3757                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">5.3</a></li>
    3758                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">5.3</a></li>
    3759                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.17">6.4.3</a></li>
    3760                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.4.3</a></li>
    3761                         <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
    3762                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.5</a></li>
    3763                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">8.6</a></li>
    3764                         <li><em>Section 7.4.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">8.6</a></li>
    3765                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
    3766                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a></li>
     3759                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.17">6.4.3</a></li>
     3760                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">6.4.3</a></li>
     3761                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.3</a></li>
     3762                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.5</a></li>
     3763                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">8.6</a></li>
     3764                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">8.6</a></li>
     3765                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.2</a></li>
     3766                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a></li>
    37673767                     </ul>
    37683768                  </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1616 r1625  
    3232  <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3333  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    34   <!ENTITY method                 "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     34  <!ENTITY methods                "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3535  <!ENTITY OPTIONS                "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3636  <!ENTITY status-code-reasonphr  "<xref target='Part2' x:rel='#status.code.and.reason.phrase' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    10421042<t>
    10431043   The methods defined by this specification can be found in
    1044    &method;, along with information regarding the HTTP method registry
     1044   &methods;, along with information regarding the HTTP method registry
    10451045   and considerations for defining new methods.
    10461046</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1621 r1625  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 27, 2012";
     462       content: "Expires September 29, 2012";
    463463  }
    464464  @bottom-right {
     
    504504      <meta name="dct.creator" content="Reschke, J. F.">
    505505      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    506       <meta name="dct.issued" scheme="ISO8601" content="2012-03-26">
     506      <meta name="dct.issued" scheme="ISO8601" content="2012-03-28">
    507507      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    508508      <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.">
     
    535535            </tr>
    536536            <tr>
    537                <td class="left">Expires: September 27, 2012</td>
     537               <td class="left">Expires: September 29, 2012</td>
    538538               <td class="right">greenbytes</td>
    539539            </tr>
    540540            <tr>
    541541               <td class="left"></td>
    542                <td class="right">March 26, 2012</td>
     542               <td class="right">March 28, 2012</td>
    543543            </tr>
    544544         </tbody>
     
    570570         in progress”.
    571571      </p>
    572       <p>This Internet-Draft will expire on September 27, 2012.</p>
     572      <p>This Internet-Draft will expire on September 29, 2012.</p>
    573573      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    574574      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p3-payload.html

    r1604 r1625  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 22, 2012";
     462       content: "Expires September 29, 2012";
    463463  }
    464464  @bottom-right {
     
    505505      <meta name="dct.creator" content="Reschke, J. F.">
    506506      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    507       <meta name="dct.issued" scheme="ISO8601" content="2012-03-21">
     507      <meta name="dct.issued" scheme="ISO8601" content="2012-03-28">
    508508      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    509509      <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 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    531531            </tr>
    532532            <tr>
    533                <td class="left">Expires: September 22, 2012</td>
     533               <td class="left">Expires: September 29, 2012</td>
    534534               <td class="right">J. Reschke, Editor</td>
    535535            </tr>
     
    540540            <tr>
    541541               <td class="left"></td>
    542                <td class="right">March 21, 2012</td>
     542               <td class="right">March 28, 2012</td>
    543543            </tr>
    544544         </tbody>
     
    568568         in progress”.
    569569      </p>
    570       <p>This Internet-Draft will expire on September 22, 2012.</p>
     570      <p>This Internet-Draft will expire on September 29, 2012.</p>
    571571      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    572572      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    10781078      </p>
    10791079      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    1080          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     1080         and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    10811081         within extension header fields not defined by this specification.
    10821082      </p>
     
    17781778      </p>
    17791779      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    1780       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     1780      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    17811781      </p>
    17821782      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
     
    22402240                  </li>
    22412241                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul>
    2242                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">A.3</a></li>
    2243                         <li><em>Section 10.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
     2242                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">A.3</a></li>
     2243                        <li><em>Section 7.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
    22442244                     </ul>
    22452245                  </li>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1624 r1625  
    13231323      <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
    13241324
    1325 <a href="#notation" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     1325<a href="#notation" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    13261326
    13271327<a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1624 r1625  
    13891389<x:ref>ETag</x:ref> = entity-tag
    13901390
    1391 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     1391<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    13921392
    13931393<x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
  • draft-ietf-httpbis/latest/p5-range.html

    r1623 r1625  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 27, 2012";
     462       content: "Expires September 29, 2012";
    463463  }
    464464  @bottom-right {
     
    503503      <meta name="dct.creator" content="Reschke, J. F.">
    504504      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    505       <meta name="dct.issued" scheme="ISO8601" content="2012-03-26">
     505      <meta name="dct.issued" scheme="ISO8601" content="2012-03-28">
    506506      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    507507      <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
     
    529529            </tr>
    530530            <tr>
    531                <td class="left">Expires: September 27, 2012</td>
     531               <td class="left">Expires: September 29, 2012</td>
    532532               <td class="right">J. Reschke, Editor</td>
    533533            </tr>
     
    538538            <tr>
    539539               <td class="left"></td>
    540                <td class="right">March 26, 2012</td>
     540               <td class="right">March 28, 2012</td>
    541541            </tr>
    542542         </tbody>
     
    566566         in progress”.
    567567      </p>
    568       <p>This Internet-Draft will expire on September 27, 2012.</p>
     568      <p>This Internet-Draft will expire on September 29, 2012.</p>
    569569      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    570570      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    13091309<a href="#header.content-range" class="smpl">Content-Range</a> = byte-content-range-spec / other-content-range-spec
    13101310
    1311 <a href="#core.rules" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     1311<a href="#core.rules" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    13121312
    13131313<a href="#header.if-range" class="smpl">If-Range</a> = entity-tag / HTTP-date
  • draft-ietf-httpbis/latest/p5-range.xml

    r1623 r1625  
    13691369<x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec
    13701370
    1371 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     1371<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    13721372
    13731373<x:ref>If-Range</x:ref> = entity-tag / HTTP-date
  • draft-ietf-httpbis/latest/p6-cache.html

    r1624 r1625  
    955955      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
    956956      <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    957          to be used (including the following in <a href="p2-semantics.html#status.codes" title="ERROR: Anchor 'status.codes' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.codes' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
     957         to be used (including the following in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
    958958      </p>
    959959      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
     
    19631963<a href="#header.expires" class="smpl">Expires</a> = HTTP-date
    19641964
    1965 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     1965<a href="#abnf.dependencies" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    19661966
    19671967<a href="#core.rules" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
     
    21822182                  </li>
    21832183                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.4">2.3.1.1</a>, <a href="#rfc.xref.Part2.5">2.3.2</a>, <a href="#rfc.xref.Part2.6">2.6</a>, <a href="#rfc.xref.Part2.7">3.3</a>, <a href="#Part2"><b>8.1</b></a><ul>
    2184                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    21852184                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2.6</a></li>
     2185                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    21862186                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
    21872187                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1624 r1625  
    3838  <!ENTITY weak-and-strong             "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3939  <!ENTITY lastmod-comparison          "<xref target='Part4' x:rel='#lastmod.comparison' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    40   <!ENTITY status-codes                "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     40  <!ENTITY status-codes                "<xref target='Part2' x:rel='#status.code.and.reason.phrase' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4141  <!ENTITY status.2xx                  "<xref target='Part2' x:rel='#status.2xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4242]>
     
    24232423<x:ref>Expires</x:ref> = HTTP-date
    24242424
    2425 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8&gt;
     2425<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 6.1&gt;
    24262426
    24272427<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
Note: See TracChangeset for help on using the changeset viewer.