Changeset 1750


Ignore:
Timestamp:
09/07/12 19:06:58 (9 years ago)
Author:
fielding@…
Message:

We do not want broad cross-references to the semantics spec within
the parsing algorithm -- it just makes it harder to understand.
Parsing needs to be independent of semantics, so we only need
the xref in one section.

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

Legend:

Unmodified
Added
Removed

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

    r1747 r1750  
    11861186         another space, a possibly-empty textual phrase describing the status code, and ending with CRLF.
    11871187      </p>
    1188       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></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" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
     1188      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></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.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a>
    11891189</pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message.
    11901190      </p>
    1191       <div id="status-code">
    1192          <p id="rfc.section.3.1.2.p.4">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.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
    1193             for new status codes.
    1194          </p>
    1195       </div>
    1196       <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#status-code" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
    1197 </pre><div id="reason-phrase">
    1198          <p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
    1199             code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
    1200             clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
    1201          </p>
    1202       </div>
    1203       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#reason-phrase" class="smpl">reason-phrase</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
     1191      <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
     1192         the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
     1193         for that status code. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1194         the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
     1195      </p>
     1196      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#status.line" class="smpl">status-code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a>
     1197</pre><p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
     1198         code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text
     1199         clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content.
     1200      </p>
     1201      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#status.line" class="smpl">reason-phrase</a>  = *( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    12041202</pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
    12051203      <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field
    … …  
    13791377      </p>
    13801378      <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1381          status code (<a href="#status-code">Paragraph&nbsp;4</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
     1379         status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.
    13821380      </p>
    13831381      <div id="rfc.iref.t.4"></div>
    … …  
    14051403      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    14061404      </p>
    1407       <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1408       </p>
    1409       <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
     1405      <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1406      </p>
     1407      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
    14101408         coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
    14111409         any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    … …  
    14271425      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Length: 3495
    14281426</pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential
    1429          transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
     1427         transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
    14301428         have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    14311429      </p>
    … …  
    17031701      </p>
    17041702      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1705       <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1703      <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17061704         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17071705         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    … …  
    17451743      </p>
    17461744      <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1747          are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
     1745         are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
    17481746         to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
    17491747         identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    … …  
    18041802      </p>
    18051803      <div id="authority-form">
    1806          <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.13"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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,
     1804         <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.12"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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,
    18071805         </p>
    18081806      </div>
    18091807      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    18101808</pre><div id="asterisk-form">
    1811          <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.14"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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,
     1809         <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.13"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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,
    18121810            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    18131811         </p>
    … …  
    19561954      </p>
    19571955      <ul>
    1958          <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
     1956         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 9.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
    19591957         </li>
    19601958         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
    19611959         </li>
    1962          <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
     1960         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>)
    19631961         </li>
    19641962      </ul>
    … …  
    19701968         </p>
    19711969      </div>
    1972       <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1970      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    19731971      </p>
    19741972      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    19751973      <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    19761974         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    1977          on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
     1975         on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, 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, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
    19781976      </p>
    19791977      <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-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.
    … …  
    21202118      <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.
    21212119      </p>
    2122       <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.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
     2120      <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.18"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
    21232121         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.
    21242122      </p>
    … …  
    21502148      <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>
    21512149      <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
    2152          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.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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
     2150         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.19"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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
    21532151         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.
    21542152      </p>
    … …  
    21632161      </p>
    21642162      <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>
    2165       <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> 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.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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
     2163      <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> 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.20"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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
    21662164         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21672165         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21702168      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21712169      <ul>
    2172          <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.
     2170         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) with the "100-continue" expectation.
    21732171         </li>
    21742172         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
    … …  
    22082206         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
    22092207         </li>
    2210          <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2208         <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22112209         </li>
    22122210      </ul>
    … …  
    22452243      </p>
    22462244      <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
    2247          is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2245         is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    22482246      </p>
    22492247      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
    … …  
    25092507         <li>Pointer to specification text</li>
    25102508      </ul>
    2511       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2509      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    25122510      </p>
    25132511      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    … …  
    26682666         that most implementations will choose substantially higher limits.
    26692667      </p>
    2670       <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.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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.27"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
     2668      <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.25"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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.26"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>).
    26712669      </p>
    26722670      <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.
    … …  
    30953093<a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
    30963094
    3097 <a href="#reason-phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text )
     3095<a href="#status.line" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text )
    30983096<a href="#header.via" class="smpl">received-by</a> = ( uri-host [ ":" port ] ) / pseudonym
    30993097<a href="#header.via" class="smpl">received-protocol</a> = [ protocol-name "/" ] protocol-version
    … …  
    31063104 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
    31073105<a href="#http.message" class="smpl">start-line</a> = request-line / status-line
    3108 <a href="#status-code" class="smpl">status-code</a> = 3DIGIT
     3106<a href="#status.line" class="smpl">status-code</a> = 3DIGIT
    31093107<a href="#status.line" class="smpl">status-line</a> = HTTP-version SP status-code SP reason-phrase CRLF
    31103108
    … …  
    37413739            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    37423740                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    3743                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.4.3</a>, <a href="#rfc.xref.Part2.24">6.5</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
     3741                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    37443742                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    3745                         <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.3.2.2</a>, <a href="#rfc.xref.Part2.20">6.3.4</a></li>
    3746                         <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
    3747                         <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
     3743                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.3.2.2</a>, <a href="#rfc.xref.Part2.19">6.3.4</a></li>
     3744                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
     3745                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
    37483746                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3749                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.3</a></li>
    3750                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">5.7</a>, <a href="#rfc.xref.Part2.23">6.4.3</a></li>
    3751                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">6.4.3</a></li>
     3747                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>
     3748                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li>
     3749                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">6.4.3</a></li>
    37523750                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    3753                         <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">6.5</a></li>
    3754                         <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">8.6</a></li>
    3755                         <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li>
    3756                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li>
    3757                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3.1</a></li>
    3758                         <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.6.2</a></li>
    3759                         <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.6.2</a></li>
     3751                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
     3752                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
     3753                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.25">8.6</a></li>
     3754                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.24">7.4</a></li>
     3755                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
     3756                        <li><em>Section 9.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.6.2</a></li>
     3757                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.6.2</a></li>
    37603758                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3761                         <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.4.3</a></li>
     3759                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">6.4.3</a></li>
    37623760                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    37633761                     </ul>
    37643762                  </li>
    3765                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
    3766                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
     3763                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
     3764                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3.1</a>, <a href="#rfc.xref.Part4.2">3.3.2</a></li>
    37673765                     </ul>
    37683766                  </li>

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

    r1747 r1750  
    11031103  <x:anchor-alias value="response"/>
    11041104  <x:anchor-alias value="status-line"/>
     1105  <x:anchor-alias value="status-code"/>
     1106  <x:anchor-alias value="reason-phrase"/>
    11051107<t>
    11061108   The first line of a response message is the status-line, consisting
    … …  
    11161118   with a status-line and matches the ABNF rule for HTTP-message.
    11171119</t>
    1118 
    1119 <t anchor="status-code">
    1120    The status-code element is a 3-digit integer result code of the attempt to
    1121    understand and satisfy the request. See &status-codes; for
    1122    further information, such as the list of status codes defined by this
    1123    specification, the IANA registry, and considerations for new status codes.
     1120<t>
     1121   The status-code element is a 3-digit integer code describing the
     1122   result of the server's attempt to understand and satisfy the client's
     1123   corresponding request. The rest of the response message is to be
     1124   interpreted in light of the semantics defined for that status code.
     1125   See &status-codes; for information about the semantics of status codes,
     1126   including the classes of status code (indicated by the first digit),
     1127   the status codes defined by this specification, considerations for the
     1128   definition of new status codes, and the IANA registry.
    11241129</t>
    11251130<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="status-code"/>
    11261131  <x:ref>status-code</x:ref>    = 3<x:ref>DIGIT</x:ref>
    11271132</artwork></figure>
    1128 
    1129 <t anchor="reason-phrase">   
     1133<t>   
    11301134   The reason-phrase element exists for the sole purpose of providing a
    11311135   textual description associated with the numeric status code, mostly
    … …  
    14981502   The presence of a message body in a response depends on both
    14991503   the request method to which it is responding and the response
    1500    status code (<xref target="status-code"/>).
     1504   status code (<xref target="status.line"/>).
    15011505   Responses to the HEAD request method never include a message body
    15021506   because the associated response header fields (e.g.,
    … …  
    15081512   <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
    15091513   All other responses do include a message body, although the body
    1510    &MAY; be of zero length. (See &status-codes; and &status-304;.)
     1514   &MAY; be of zero length.
    15111515</t>
    15121516
Note: See TracChangeset for help on using the changeset viewer.