Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

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

    r992 r994  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-09-06">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: March 10, 2011</td>
     437               <td class="left">Expires: March 11, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">September 6, 2010</td>
     490               <td class="right">September 7, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire on March 10, 2011.</p>
     518      <p>This Internet-Draft will expire on March 11, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    608608                     </li>
    609609                     <li class="tocline1">7.1.3&nbsp;&nbsp;&nbsp;<a href="#persistent.proxy">Proxy Servers</a><ul class="toc">
    610                            <li class="tocline1">7.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li>
    611                            <li class="tocline1">7.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.headers">Non-modifiable Headers</a></li>
     610                           <li class="tocline1">7.1.3.1&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
     611                           <li class="tocline1">7.1.3.2&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
    612612                        </ul>
    613613                     </li>
     
    11881188      </p>
    11891189      <div class="note" id="rfc.section.3.2.p.7">
    1190          <p> <b>Note:</b> The "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
    1191             A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
     1190         <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
     1191            A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
    11921192         </p>
    11931193      </div>
     
    17231723      </p>
    17241724      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
    1725       <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1725      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17261726         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
    17271727         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.
     
    17681768      </p>
    17691769      <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
    1770       <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token
    1771          "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token "close".
     1770      <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header field including the connection-token
     1771         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token "close".
    17721772      </p>
    17731773      <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
    1774          a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than
    1775          that request, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.
    1776       </p>
    1777       <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the
    1778          connection.
     1774         a Connection header field with the connection-token close. In case the client does not want to maintain a connection for more
     1775         than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection-token close.
     1776      </p>
     1777      <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header field, that request becomes the last one
     1778         for the connection.
    17791779      </p>
    17801780      <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
     
    17961796         to. Each persistent connection applies to only one transport link.
    17971797      </p>
    1798       <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
    1799       </p>
    1800       <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.headers" href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></h4>
    1801       <p id="rfc.section.7.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories: </p>
    1802       <ul>
    1803          <li>End-to-end headers, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses
    1804             MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
    1805          </li>
    1806          <li>Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded
    1807             by proxies.
    1808          </li>
    1809       </ul>
    1810       <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 headers are hop-by-hop headers: </p>
     1798      <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
     1799      </p>
     1800      <h4 id="rfc.section.7.1.3.1"><a href="#rfc.section.7.1.3.1">7.1.3.1</a>&nbsp;<a id="end-to-end.and.hop-by-hop.header-fields" href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></h4>
     1801      <p id="rfc.section.7.1.3.1.p.1">For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP header fields into two categories: </p>
     1802      <ul>
     1803         <li>End-to-end header fields, which are transmitted to the ultimate recipient of a request or response. End-to-end header fields
     1804            in responses MUST be stored as part of a cache entry and <em class="bcp14">MUST</em> be transmitted in any response formed from a cache entry.
     1805         </li>
     1806         <li>Hop-by-hop header fields, which are meaningful only for a single transport-level connection, and are not stored by caches
     1807            or forwarded by proxies.
     1808         </li>
     1809      </ul>
     1810      <p id="rfc.section.7.1.3.1.p.2">The following HTTP/1.1 header fields are hop-by-hop header fields: </p>
    18111811      <ul>
    18121812         <li>Connection</li>
     
    18191819         <li>Upgrade</li>
    18201820      </ul>
    1821       <p id="rfc.section.7.1.3.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p>
    1822       <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>).
    1823       </p>
    1824       <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h4>
    1825       <p id="rfc.section.7.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent
    1826          proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
     1821      <p id="rfc.section.7.1.3.1.p.3">All other header fields defined by HTTP/1.1 are end-to-end header fields.</p>
     1822      <p id="rfc.section.7.1.3.1.p.4">Other hop-by-hop header fields <em class="bcp14">MUST</em> be listed in a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;9.1</a>).
     1823      </p>
     1824      <h4 id="rfc.section.7.1.3.2"><a href="#rfc.section.7.1.3.2">7.1.3.2</a>&nbsp;<a id="non-modifiable.header-fields" href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></h4>
     1825      <p id="rfc.section.7.1.3.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end header fields. A transparent
     1826         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header field unless the definition of that header field requires or specifically allows that.
    18271827      </p>
    18281828      <p id="rfc.section.7.1.3.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present:
     
    18391839         <li>Expires</li>
    18401840      </ul>
    1841       <p id="rfc.section.7.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header in that response.
     1841      <p id="rfc.section.7.1.3.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
    18421842      </p>
    18431843      <p id="rfc.section.7.1.3.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
     
    18511851      </p>
    18521852      <div class="note" id="rfc.section.7.1.3.2.p.7">
    1853          <p> <b>Warning:</b> Unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are
    1854             introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
     1853         <p> <b>Warning:</b> Unnecessary modification of end-to-end header fields might cause authentication failures if stronger authentication mechanisms
     1854            are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    18551855         </p>
    18561856      </div>
     
    18951895      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    18961896      <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    1897          status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.
     1897         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    18981898      </p>
    18991899      <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>
    19001900      <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 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><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
    1901          to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
    1902          be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
    1903          at the body.
     1901         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
     1902         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     1903         looking at the body.
    19041904      </p>
    19051905      <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
     
    19611961      <ol>
    19621962         <li>Initiate a new connection to the server</li>
    1963          <li>Transmit the request-headers</li>
     1963         <li>Transmit the request-header fields</li>
    19641964         <li>Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection),
    19651965            or to a constant value of 5 seconds if the round-trip time is not available.
     
    20032003         and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
    20042004      </p>
    2005       <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p>
     2005      <p id="rfc.section.9.1.p.2">The Connection header field's value has the following grammar:</p>
    20062006      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span>  <a href="#header.connection" class="smpl">Connection</a>       = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>
    20072007  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
     
    20122012         header field might not be sent if there are no parameters associated with that connection option.
    20132013      </p>
    2014       <p id="rfc.section.9.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control.
     2014      <p id="rfc.section.9.1.p.5">Message header fields listed in the Connection header field <em class="bcp14">MUST NOT</em> include end-to-end header fields, such as Cache-Control.
    20152015      </p>
    20162016      <p id="rfc.section.9.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion
     
    20242024      <p id="rfc.section.9.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (Informational) status code.
    20252025      </p>
    2026       <p id="rfc.section.9.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the
     2026      <p id="rfc.section.9.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header field <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the
    20272027         connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a>.
    20282028      </p>
     
    20742074         then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request.
    20752075      </p>
    2076       <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
     2076      <p id="rfc.section.9.3.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    20772077         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
    20782078         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
     
    21912191</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    21922192      </p>
    2193       <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>
     2193      <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p>
    21942194      <div id="rfc.iref.u.5"></div>
    21952195      <div id="rfc.iref.h.14"></div>
     
    28662866      <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers <em class="bcp14">SHOULD</em> be tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
    28672867      </p>
    2868       <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers,
    2869          recognize a single LF as a line terminator and ignore the leading CR.
     2868      <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers
     2869         fields, recognize a single LF as a line terminator and ignore the leading CR.
    28702870      </p>
    28712871      <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
     
    28842884         <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
    28852885         </li>
    2886          <li>If an HTTP header incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion.
     2886         <li>If an HTTP header field incorrectly carries a date value with a time zone other than GMT, it <em class="bcp14">MUST</em> be converted into GMT using the most conservative possible conversion.
    28872887         </li>
    28882888      </ul>
     
    29192919      <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
    29202920      <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>
    2921       <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
     2921      <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification.
    29222922      </p>
    29232923      <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism
     
    29312931      </p>
    29322932      <ul>
    2933          <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header.
    2934          </li>
    2935          <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header.
    2936          </li>
    2937          <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header.
     2933         <li>Both clients and servers <em class="bcp14">MUST</em> support the Host request-header field.
     2934         </li>
     2935         <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field.
     2936         </li>
     2937         <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header field.
    29382938         </li>
    29392939         <li>Servers <em class="bcp14">MUST</em> accept absolute URIs.
     
    29542954         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;9.1</a>.
    29552955      </p>
    2956       <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     2956      <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented
     2957         in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    29572958      </p>
    29582959      <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
     
    32603261         <li>Get rid of prose rules that span multiple lines.</li>
    32613262         <li>Get rid of unused rules LOALPHA and UPALPHA.</li>
    3262          <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li>
     3263         <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li>
    32633264         <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
    32643265         <li>Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT".</li>
     
    32723273         </li>
    32733274      </ul>
    3274       <p id="rfc.section.D.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    3275       </p>
    3276       <ul>
    3277          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     3275      <p id="rfc.section.D.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     3276      </p>
     3277      <ul>
     3278         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    32783279      </ul>
    32793280      <p id="rfc.section.D.4.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
     
    33193320         <li>Only reference RFC 5234's core rules.</li>
    33203321         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    3321          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     3322         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    33223323      </ul>
    33233324      <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p1-messaging-05</a></h2>
     
    33543355      <ul>
    33553356         <li>Rewrite introduction; add mostly new Architecture Section.</li>
    3356          <li>Move definition of quality values from Part 3 into Part 1; make TE request header grammar independent of accept-params (defined
    3357             in Part 3).
     3357         <li>Move definition of quality values from Part 3 into Part 1; make TE request header field grammar independent of accept-params
     3358            (defined in Part 3).
    33583359         </li>
    33593360      </ul>
Note: See TracChangeset for help on using the changeset viewer.