Changeset 1420 for draft-ietf-httpbis


Ignore:
Timestamp:
Aug 30, 2011, 6:53:41 AM (8 years ago)
Author:
julian.reschke@…
Message:

add references from P1 to header field/method/status code chapters in P2 (see #215)

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

Legend:

Unmodified
Added
Removed

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

    r1416 r1420  
    359359  }
    360360  @bottom-center {
    361        content: "Expires February 27, 2012";
     361       content: "Expires March 2, 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-08-26">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-08-30">
    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: February 27, 2012</td>
     443               <td class="left">Expires: March 2, 2012</td>
    444444               <td class="right">HP</td>
    445445            </tr>
    … …  
    494494            <tr>
    495495               <td class="left"></td>
    496                <td class="right">August 26, 2011</td>
     496               <td class="right">August 30, 2011</td>
    497497            </tr>
    498498         </tbody>
    … …  
    527527         in progress”.
    528528      </p>
    529       <p>This Internet-Draft will expire on February 27, 2012.</p>
     529      <p>This Internet-Draft will expire on March 2, 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>
    … …  
    12251225         them.
    12261226      </p>
    1227       <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;10.1</a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
     1227      <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section&nbsp;9.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.
    12281228      </p>
    12291229      <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice"
    … …  
    14731473      <p id="rfc.section.4.1.1.p.1">The Method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
    14741474      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1475 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
     1475</pre><p id="rfc.section.4.1.1.p.3">See <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> for further information, such as the list of methods defined by this specification, the IANA registry, and considerations
     1476         for new methods.
     1477      </p>
     1478      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="request-target" href="#request-target">request-target</a></h3>
    14761479      <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request. In most cases, the user agent is provided
    14771480         a URI reference from which it determines an absolute URI for identifying the target resource. When a request to the resource
    … …  
    14971500      <p id="rfc.section.4.1.2.p.9">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
    14981501      </p>
    1499       <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1502      <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 6.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    15001503      </p>
    15011504      <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case,
    … …  
    15301533      </div>
    15311534      <p id="rfc.section.4.1.2.p.20">HTTP does not place a pre-defined limit on the length of a request-target. 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
    1532          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.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1535         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.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    15331536      </p>
    15341537      <p id="rfc.section.4.1.2.p.21">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
    … …  
    16101613      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.50"></span>  <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    16111614</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    1612       <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
    1613          are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
     1615      <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <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.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
     1616         for new status codes.
     1617      </p>
     1618      <p id="rfc.section.5.1.1.p.2">The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
    16141619         out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
    16151620         client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
    16161621      </p>
    1617       <p id="rfc.section.5.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
     1622      <p id="rfc.section.5.1.1.p.3">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
    16181623         There are 5 values for the first digit:
    16191624      </p>
    … …  
    19341939      <p id="rfc.section.7.1.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.
    19351940      </p>
    1936       <p id="rfc.section.7.1.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.5"><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
     1941      <p id="rfc.section.7.1.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.7"><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
    19371942         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.
    19381943      </p>
    … …  
    20202025      </p>
    20212026      <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
    2022          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.6"><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
     2027         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.8"><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
    20232028         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.
    20242029      </p>
    … …  
    20472052      </p>
    20482053      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2049       <p id="rfc.section.7.2.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.7"><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
     2054      <p id="rfc.section.7.2.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.9"><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
    20502055         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    20512056         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    20542059      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
    20552060      <ul>
    2056          <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 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2057          </li>
    2058          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><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.
     2061         <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 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2062         </li>
     2063         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 8.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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.
    20592064         </li>
    20602065      </ul>
    … …  
    21002105         <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
    21012106            an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2102             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.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2107            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.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    21032108         </li>
    21042109      </ul>
    … …  
    23762381      </p>
    23772382      <p id="rfc.section.9.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
    2378          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.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2383         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.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    23792384      </p>
    23802385      <p id="rfc.section.9.8.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
    … …  
    28042809         that most implementations will choose substantially higher limits.
    28052810      </p>
    2806       <p id="rfc.section.11.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.15</a> of <a href="#Part2" id="rfc.xref.Part2.12"><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.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2811      <p id="rfc.section.11.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.15</a> of <a href="#Part2" id="rfc.xref.Part2.14"><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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    28072812      </p>
    28082813      <p id="rfc.section.11.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.
    … …  
    36503655      <p id="rfc.section.C.18.p.1">Closed issues: </p>
    36513656      <ul>
     3657         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>&gt;: "Explain header registration"
     3658         </li>
    36523659         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/219">http://tools.ietf.org/wg/httpbis/trac/ticket/219</a>&gt;: "Revise Acknowledgements Sections"
    36533660         </li>
    … …  
    38733880            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    38743881                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">7.1.1</a>, <a href="#Pad1995"><b>13.2</b></a></li>
    3875                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">4.1.2</a>, <a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.4">5.1.1</a>, <a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a>, <a href="#rfc.xref.Part2.7">7.2.3</a>, <a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">9.8</a>, <a href="#rfc.xref.Part2.12">11.6</a>, <a href="#rfc.xref.Part2.13">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul>
    3876                         <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">7.1.2.2</a>, <a href="#rfc.xref.Part2.6">7.1.4</a></li>
    3877                         <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">4.1.2</a></li>
    3878                         <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">5.1.1</a></li>
    3879                         <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.2.3</a></li>
    3880                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">7.2.3</a></li>
     3882                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a>, <a href="#rfc.xref.Part2.2">3.2</a>, <a href="#rfc.xref.Part2.3">4.1.1</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">4.1.2</a>, <a href="#rfc.xref.Part2.6">5.1.1</a>, <a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a>, <a href="#rfc.xref.Part2.9">7.2.3</a>, <a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a>, <a href="#rfc.xref.Part2.12">7.2.3</a>, <a href="#rfc.xref.Part2.13">9.8</a>, <a href="#rfc.xref.Part2.14">11.6</a>, <a href="#rfc.xref.Part2.15">11.6</a>, <a href="#Part2"><b>13.1</b></a><ul>
     3883                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.1</a></li>
     3884                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">3.2</a></li>
     3885                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">5.1.1</a></li>
     3886                        <li><em>Section 6.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.1.2.2</a>, <a href="#rfc.xref.Part2.8">7.1.4</a></li>
     3887                        <li><em>Section 6.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.2</a></li>
     3888                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">7.2.3</a></li>
     3889                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">7.2.3</a></li>
    38813890                        <li><em>Section 7.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.4</a></li>
    3882                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">9.8</a></li>
    3883                         <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">11.6</a></li>
    3884                         <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1.2</a>, <a href="#rfc.xref.Part2.12">11.6</a></li>
    3885                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">7.2.3</a>, <a href="#rfc.xref.Part2.9">7.2.3</a></li>
     3891                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">9.8</a></li>
     3892                        <li><em>Section 7.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">11.6</a></li>
     3893                        <li><em>Section 7.4.15</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1.2</a>, <a href="#rfc.xref.Part2.14">11.6</a></li>
     3894                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">7.2.3</a>, <a href="#rfc.xref.Part2.11">7.2.3</a></li>
    38863895                     </ul>
    38873896                  </li>

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

    r1414 r1420  
    3131  <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     33  <!ENTITY method                 "<xref target='Part2' x:rel='#method' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     34  <!ENTITY status-code-reasonphr  "<xref target='Part2' x:rel='#status.code.and.reason.phrase' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3335  <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3436  <!ENTITY status-100             "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    3840  <!ENTITY status-4xx             "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3941  <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     42  <!ENTITY cons-new-header-fields "<xref target='Part2' x:rel='#considerations.for.creating.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    4043]>
    4144<?rfc toc="yes" ?>
    … …  
    12411244<t>
    12421245   New HTTP header fields &SHOULD; be registered with IANA according
    1243    to the procedures in <xref target="header.field.registration"/>.
     1246   to the procedures in &cons-new-header-fields;.
    12441247   Unrecognized header fields &MUST; be forwarded by a proxy unless the
    12451248   field-name is listed in the Connection header field
    … …  
    16981701  <x:ref>Method</x:ref>         = <x:ref>token</x:ref>
    16991702</artwork></figure>
     1703<t>
     1704   See &method; for further information, such as the list of methods defined
     1705   by this specification, the IANA registry, and considerations for new methods.
     1706</t>
    17001707</section>
    17011708
    … …  
    19932000  <x:anchor-alias value="Status-Code"/>
    19942001<t>
    1995    The Status-Code element is a 3-digit integer result code of the
    1996    attempt to understand and satisfy the request. These codes are fully
    1997    defined in &status-codes;.  The Reason Phrase exists for the sole
    1998    purpose of providing a textual description associated with the numeric
    1999    status code, out of deference to earlier Internet application protocols
    2000    that were more frequently used with interactive text clients.
    2001    A client &SHOULD; ignore the content of the Reason Phrase.
     2002   The Status-Code element is a 3-digit integer result code of the attempt to
     2003   understand and satisfy the request. See &status-code-reasonphr; for
     2004   further information, such as the list of status codes defined by this
     2005   specification, the IANA registry, and considerations for new status codes.
     2006</t>
     2007<t>   
     2008   The Reason Phrase exists for the sole purpose of providing a textual
     2009   description associated with the numeric status code, out of deference to
     2010   earlier Internet application protocols that were more frequently used with
     2011   interactive text clients. A client &SHOULD; ignore the content of the Reason
     2012   Phrase.
    20022013</t>
    20032014<t>
    … …  
    61586169  <list style="symbols">
    61596170    <t>
     6171      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>:
     6172      "Explain header registration"
     6173    </t>
     6174    <t>
    61606175      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/219"/>:
    61616176      "Revise Acknowledgements Sections"

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

    r1417 r1420  
    359359  }
    360360  @bottom-center {
    361        content: "Expires February 29, 2012";
     361       content: "Expires March 2, 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-08-28">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-08-30">
    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: February 29, 2012</td>
     441               <td class="left">Expires: March 2, 2012</td>
    442442               <td class="right">HP</td>
    443443            </tr>
    … …  
    492492            <tr>
    493493               <td class="left"></td>
    494                <td class="right">August 28, 2011</td>
     494               <td class="right">August 30, 2011</td>
    495495            </tr>
    496496         </tbody>
    … …  
    522522         in progress”.
    523523      </p>
    524       <p>This Internet-Draft will expire on February 29, 2012.</p>
     524      <p>This Internet-Draft will expire on March 2, 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>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1416 r1420  
    359359  }
    360360  @bottom-center {
    361        content: "Expires February 27, 2012";
     361       content: "Expires March 2, 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-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-08-26">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-08-30">
    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 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: February 27, 2012</td>
     436               <td class="left">Expires: March 2, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">August 26, 2011</td>
     493               <td class="right">August 30, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    519519         in progress”.
    520520      </p>
    521       <p>This Internet-Draft will expire on February 27, 2012.</p>
     521      <p>This Internet-Draft will expire on March 2, 2012.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

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

    r1415 r1420  
    359359  }
    360360  @bottom-center {
    361        content: "Expires February 27, 2012";
     361       content: "Expires March 2, 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-p7-auth-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2011-08-26">
     406      <meta name="dct.issued" scheme="ISO8601" content="2011-08-30">
    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, 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 the HTTP Authentication framework.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: February 27, 2012</td>
     437               <td class="left">Expires: March 2, 2012</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">August 26, 2011</td>
     490               <td class="right">August 30, 2011</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on February 27, 2012.</p>
     518      <p>This Internet-Draft will expire on March 2, 2012.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.