Ignore:
Timestamp:
Mar 10, 2011, 10:45:43 PM (9 years ago)
Author:
fielding@…
Message:

update generated HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1162 r1164  
    411411      <meta name="dct.issued" scheme="ISO8601" content="2011-03-10">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    414       <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
     413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
     414      <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    415415   </head>
    416416   <body>
     
    502502         systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the
    503503         seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part
    504          2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and
    505          response-header fields.
     504         2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and
     505         response header fields.
    506506      </p>
    507507      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
     
    709709      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    710710         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections will
    711          be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general
    712          header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed
    713          these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     711         be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, methods,
     712         request modifying header fields, response status, status modifying header fields, and resource metadata. The current mess
     713         reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    714714      </p>
    715715      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    861861      </p>
    862862      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>
    863       <p id="rfc.section.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,
     863      <p id="rfc.section.3.p.1">The request header fields allow the client to pass additional information about the request, and about the client itself,
    864864         to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language
    865865         method invocation.
     
    953953         </table>
    954954      </div>
    955       <p id="rfc.section.3.p.2">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    956          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
    957       </p>
    958955      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
    959956      <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.</p>
     
    12161213      </p>
    12171214      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>
    1218       <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
     1215      <p id="rfc.section.5.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    12191216         Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    12201217      </p>
     
    12231220            <thead>
    12241221               <tr>
    1225                   <th>Method Name</th>
     1222                  <th>Header Field Name</th>
    12261223                  <th>Defined in...</th>
    12271224               </tr>
     
    12711268         </table>
    12721269      </div>
    1273       <p id="rfc.section.5.p.2">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    1274          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
    1275          fields.
    1276       </p>
    12771270      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    12781271      <p id="rfc.section.6.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
     
    13561349         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
    13571350      </p>
    1358       <p id="rfc.section.7.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     1351      <p id="rfc.section.7.2.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
    13591352      </p>
    13601353      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="GET" href="#GET">GET</a></h2>
     
    18691862      <div id="rfc.iref.s.31"></div>
    18701863      <h3 id="rfc.section.8.4.13"><a href="#rfc.section.8.4.13">8.4.13</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h3>
    1871       <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as
    1872          defined in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     1864      <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the header fields evaluated to false when it was tested on the server, as defined
     1865         in <a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.16"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    18731866      </p>
    18741867      <div id="rfc.iref.52"></div>
     
    18981891      <div id="rfc.iref.s.35"></div>
    18991892      <h3 id="rfc.section.8.4.17"><a href="#rfc.section.8.4.17">8.4.17</a>&nbsp;<a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3>
    1900       <p id="rfc.section.8.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
     1893      <p id="rfc.section.8.4.17.p.1">The request included a Range header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.12"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. See <a href="p5-range.html#status.416" title="416 Requested Range Not Satisfiable">Section 3.2</a> of <a href="#Part5" id="rfc.xref.Part5.13"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
    19011894      </p>
    19021895      <div id="rfc.iref.56"></div>
    19031896      <div id="rfc.iref.s.36"></div>
    19041897      <h3 id="rfc.section.8.4.18"><a href="#rfc.section.8.4.18">8.4.18</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
    1905       <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
     1898      <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
    19061899         not be met by the next-hop server.
    19071900      </p>
     
    19731966      <div id="rfc.iref.h.2"></div>
    19741967      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    1975       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
    1976          this field is strictly to inform the recipient of valid request methods associated with the resource.
     1968      <p id="rfc.section.9.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field
     1969         is strictly to inform the recipient of valid request methods associated with the resource.
    19771970      </p>
    19781971      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
     
    19871980      <div id="rfc.iref.h.3"></div>
    19881981      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    1989       <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p>
     1982      <p id="rfc.section.9.2.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
    19901983      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#header.expect" class="smpl">Expect</a>       = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a>
    19911984  <a href="#header.expect" class="smpl">Expect-v</a>     = 1#<a href="#header.expect" class="smpl">expectation</a>
     
    20051998      </p>
    20061999      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
    2007          Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     2000         Expect header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    20082001      </p>
    20092002      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
     
    20132006      <div id="rfc.iref.h.4"></div>
    20142007      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
    2015       <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
     2008      <p id="rfc.section.9.3.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    20162009      </p>
    20172010      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.from" class="smpl">From</a>    = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a>
     
    20352028      <div id="rfc.iref.h.5"></div>
    20362029      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    2037       <p id="rfc.section.9.4.p.1">The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different
    2038          location for completion of the request.
     2030      <p id="rfc.section.9.4.p.1">The "Location" header field is used to identify a newly created resource, or to redirect the recipient to a different location
     2031         for completion of the request.
    20392032      </p>
    20402033      <p id="rfc.section.9.4.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
     
    20672060      <div id="rfc.iref.h.6"></div>
    20682061      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    2069       <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client
     2062      <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client
    20702063         is attempting to trace a request which appears to be failing or looping in mid-chain.
    20712064      </p>
     
    20802073      <div id="rfc.iref.h.7"></div>
    20812074      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    2082       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request
    2083          URI was obtained (the "referrer", although the header field is misspelled.).
     2075      <p id="rfc.section.9.6.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI
     2076         was obtained (the "referrer", although the header field is misspelled.).
    20842077      </p>
    20852078      <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
     
    21002093      <div id="rfc.iref.h.8"></div>
    21012094      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
    2102       <p id="rfc.section.9.7.p.1">The response-header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service
    2103          is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing
     2095      <p id="rfc.section.9.7.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
     2096         to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing
    21042097         the redirected request.
    21052098      </p>
     
    21182111      <div id="rfc.iref.h.9"></div>
    21192112      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    2120       <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p>
     2113      <p id="rfc.section.9.8.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>
    21212114      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    21222115         identifying the application.
     
    21272120</pre><p id="rfc.section.9.8.p.4">Example:</p>
    21282121      <div id="rfc.figure.u.28"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2129 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2122</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    21302123      </p>
    21312124      <div class="note" id="rfc.section.9.8.p.7">
     
    21382131      <div id="rfc.iref.h.10"></div>
    21392132      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
    2140       <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
     2133      <p id="rfc.section.9.9.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.
    21412134      </p>
    21422135      <p id="rfc.section.9.9.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular
Note: See TracChangeset for help on using the changeset viewer.