Ignore:
Timestamp:
Jul 24, 2010, 12:25:24 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

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

    r900 r902  
    382382      <link rel="Chapter" title="6 Protocol Parameters" href="#rfc.section.6">
    383383      <link rel="Chapter" title="7 Connections" href="#rfc.section.7">
    384       <link rel="Chapter" title="8 Miscellaneous notes that may disappear" href="#rfc.section.8">
     384      <link rel="Chapter" title="8 Miscellaneous notes that might disappear" href="#rfc.section.8">
    385385      <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9">
    386386      <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10">
     
    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-07-23">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
    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: January 24, 2011</td>
     437               <td class="left">Expires: January 25, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 23, 2010</td>
     490               <td class="right">July 24, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire in January 24, 2011.</p>
     518      <p>This Internet-Draft will expire in January 25, 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>
     
    624624            </ul>
    625625         </li>
    626          <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#misc">Miscellaneous notes that may disappear</a><ul class="toc">
     626         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#misc">Miscellaneous notes that might disappear</a><ul class="toc">
    627627               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#scheme.aliases">Scheme aliases considered harmful</a></li>
    628628               <li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#http.proxy">Use of HTTP for proxy communication</a></li>
     
    726726         we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of
    727727         recipients. If the communication is considered in isolation, then successful actions should be reflected in corresponding
    728          changes to the observable interface provided by servers. However, since multiple clients may act in parallel and perhaps at
    729          cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
     728         changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps
     729         at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
    730730      </p>
    731731      <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 describes the architectural elements that are used or referred to in HTTP, defines the "http" and "https" URI schemes,
     
    808808         </p>
    809809      </div>
    810       <p id="rfc.section.1.2.2.p.3">The OWS rule is used where zero or more linear whitespace characters may appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP character. Multiple OWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
     810      <p id="rfc.section.1.2.2.p.3">The OWS rule is used where zero or more linear whitespace characters might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP character. Multiple OWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
    811811      </p>
    812812      <p id="rfc.section.1.2.2.p.4">RWS is used when at least one linear whitespace character is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP character. Multiple RWS characters that occur within field-content <em class="bcp14">SHOULD</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
     
    878878      <div id="rfc.iref.o.1"></div>
    879879      <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
    880          same program may act as a client on some connections and a server on others. We use the term "user agent" to refer to the
     880         same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the
    881881         program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
    882882         to refer to the program that can originate authoritative responses to a request.
    883883      </p>
    884884      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
    885          the simplest case, this may be accomplished via a single bidirectional connection (===) between the user agent (UA) and the
    886          origin server (O).
     885         the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and
     886         the origin server (O).
    887887      </p>
    888888      <div id="rfc.figure.u.15"></div><pre class="drawing">         request   &gt;
     
    921921</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    922922      <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
    923          common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary may act as an origin server,
     923         common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server,
    924924         proxy, gateway, or tunnel, switching behavior based on the nature of each request.
    925925      </p>
     
    928928               &lt;             &lt;             &lt;             &lt;
    929929</pre><p id="rfc.section.2.2.p.3">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response
    930          message that travels the whole chain will pass through four separate connections. Some HTTP communication options may apply
     930         message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply
    931931         only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along
    932          the chain. Although the diagram is linear, each participant may be engaged in multiple, simultaneous communications. For example,
    933          B may be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same
    934          time that it is handling A's request.
     932         the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For
     933         example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C,
     934         at the same time that it is handling A's request.
    935935      </p>
    936936      <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.1"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
     
    940940      <p id="rfc.section.2.2.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive
    941941         requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.
    942          Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests may require translation
     942         Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation
    943943         to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests
    944944         through a common intermediary for the sake of security, annotation services, or shared caching.
     
    953953      </p>
    954954      <p id="rfc.section.2.2.p.7"><span id="rfc.iref.t.1"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    955          a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. A tunnel ceases to exist
     955         a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist
    956956         when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,
    957957         such as when transport-layer security is used to establish private communication through a shared firewall proxy.
     
    959959      <div id="rfc.iref.c.3"></div>
    960960      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    961       <p id="rfc.section.2.3.p.1">Any party to HTTP communication that is not acting as a tunnel may employ an internal cache for handling requests. A "cache"
    962          is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
    963          A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    964          requests. Any client or server may include a cache, though a cache cannot be used by a server while it is acting as a tunnel.
     961      <p id="rfc.section.2.3.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and
     962         deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future,
     963         equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
    965964      </p>
    966965      <p id="rfc.section.2.3.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
     
    972971                  &lt;             &lt;
    973972</pre><p id="rfc.section.2.3.p.4"><span id="rfc.iref.c.4"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    974          Even when a response is cacheable, there may be additional constraints placed by the client or by the origin server on when
     973         Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when
    975974         that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
    976975         defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     
    990989         the scope of this specification.
    991990      </p>
    992       <p id="rfc.section.2.4.p.3">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may
    993          be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>).
     991      <p id="rfc.section.2.4.p.3">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection might
     992         be used for one or more request/response exchanges, although connections might be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section&nbsp;7.1</a>).
    994993      </p>
    995994      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="http.version" href="#http.version">HTTP Version</a></h2>
     
    998997         than the features obtained via that communication. No change is made to the version number for the addition of message components
    999998         which do not affect communication behavior or which only add to extensible field values. The &lt;minor&gt; number is incremented
    1000          when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
     999         when the changes made to the protocol add features which do not change the general message parsing algorithm, but which might
    10011000         add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
    10021001         of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation.
     
    10201019      </p>
    10211020      <div class="note" id="rfc.section.2.5.p.9">
    1022          <p> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
     1021         <p> <b>Note:</b> Converting between versions of HTTP might involve modification of header fields required or forbidden by the versions involved.
    10231022         </p>
    10241023      </div>
     
    10261025      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    10271026      <p id="rfc.section.2.6.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, indicate redirects,
    1028          and define relationships. HTTP does not limit what a resource may be; it merely defines an interface that can be used to interact
    1029          with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
     1027         and define relationships. HTTP does not limit what a resource might be; it merely defines an interface that can be used to
     1028         interact with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>.
    10301029      </p>
    10311030      <p id="rfc.section.2.6.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty",
     
    10631062      </p>
    10641063      <p id="rfc.section.2.6.1.p.4">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.
    1065          The host may or may not exist and, even when it does exist, may or may not be running an HTTP server or listening to the indicated
    1066          port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish a naming authority
    1067          (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that authority to determine
    1068          which names are valid and how they might be used.
     1064         The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening
     1065         to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish
     1066         a naming authority (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that
     1067         authority to determine which names are valid and how they might be used.
    10691068      </p>
    10701069      <p id="rfc.section.2.6.1.p.5">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
     
    10741073         delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol
    10751074         would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require
    1076          an SSL/TLS transport layer on a connection. Other protocols may also be used to provide access to "http" identified resources
     1075         an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources
    10771076         --- it is only the authoritative interface used for mapping the namespace that is specific to TCP.
    10781077      </p>
     
    10911090      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ]
    10921091</pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus are ineligible for shared caching.
    1093          Their default is "private" and may be further constrained via use of the Cache-Control header field.
     1092         Their default is "private" and might be further constrained via use of the Cache-Control header field.
    10941093      </p>
    10951094      <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers
     
    11361135  <a href="#http.message" class="smpl">start-line</a>      = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a>
    11371136</pre><p id="rfc.section.3.p.4">Whitespace (WSP) <em class="bcp14">MUST NOT</em> be sent between the start-line and the first header field. The presence of whitespace might be an attempt to trick a noncompliant
    1138          implementation of HTTP into ignoring that field or processing the next line as a new request, either of which may result in
    1139          security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response.
     1137         implementation of HTTP into ignoring that field or processing the next line as a new request, either of which might result
     1138         in security issues when implementations within the request chain interpret the same message differently. HTTP/1.1 servers <em class="bcp14">MUST</em> reject such a message with a 400 (Bad Request) response.
    11401139      </p>
    11411140      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
     
    11521151         is read or the connection is closed. Care must be taken to parse an HTTP message as a sequence of octets in an encoding that
    11531152         is a superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16
    1154          may introduce security flaws due to the differing ways that such parsers interpret invalid characters.
     1153         might introduce security flaws due to the differing ways that such parsers interpret invalid characters.
    11551154      </p>
    11561155      <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>
     
    12401239            </p>
    12411240            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
    1242                overrides the Content-Length. Such a message may indicate an attempt to perform request or response smuggling (bypass of security-related
    1243                checks on message routing or content) and thus should be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
     1241               overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of
     1242               security-related checks on message routing or content) and thus should be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
    12441243               is decoded.
    12451244            </p>
     
    13041303                 / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
    13051304</pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    1306          or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
     1305         or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
    13071306         them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
    13081307      </p>
     
    15471546                 ; month day (e.g., Jun  2)
    15481547</pre><div class="note" id="rfc.section.6.1.p.15">
    1549          <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
     1548         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications,
    15501549            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    15511550         </p>
     
    15571556      </div>
    15581557      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>
    1559       <p id="rfc.section.6.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to
    1560          a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding
    1561          is a property of the message rather than a property of the representation that is being transferred.
     1558      <p id="rfc.section.6.2.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or might need to be applied
     1559         to a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the
     1560         transfer-coding is a property of the message rather than a property of the representation that is being transferred.
    15621561      </p>
    15631562      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>
     
    18991898         </li>
    19001899      </ul>
    1901       <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect:
     1900      <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    19021901         100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client
    19031902         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the
     
    19681967         </li>
    19691968      </ul>
    1970       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that may disappear</a></h1>
     1969      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1>
    19711970      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2>
    19721971      <p id="rfc.section.8.1.p.1"> <span class="comment" id="TBD-aliases-harmful">[<a href="#TBD-aliases-harmful" class="smpl">TBD-aliases-harmful</a>: describe why aliases like webcal are harmful.]</span>
     
    20022001         field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a
    20032002         connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional
    2004          header field may not be sent if there are no parameters associated with that connection option.
     2003         header field might not be sent if there are no parameters associated with that connection option.
    20052004      </p>
    20062005      <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.
     
    21052104         or not it is willing to accept trailer fields in a chunked transfer-coding.
    21062105      </p>
    2107       <p id="rfc.section.9.5.p.2">Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     2106      <p id="rfc.section.9.5.p.2">Its value might consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    21082107         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
    21092108      </p>
     
    26142613         this problem.
    26152614      </p>
    2616       <p id="rfc.section.11.5.p.5">The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy
     2615      <p id="rfc.section.11.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy
    26172616         attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
    26182617      </p>
     
    26792678         <tr>
    26802679            <td class="reference"><b id="RFC1950">[RFC1950]</b></td>
    2681             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it may be less stable than this specification. On the other hand, this downward reference
     2680            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    26822681               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    26832682            </td>
     
    26852684         <tr>
    26862685            <td class="reference"><b id="RFC1951">[RFC1951]</b></td>
    2687             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it may be less stable than this specification. On the other hand, this downward reference
     2686            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    26882687               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    26892688            </td>
     
    26912690         <tr>
    26922691            <td class="reference"><b id="RFC1952">[RFC1952]</b></td>
    2693             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it may be less stable than this specification. On the other hand, this downward reference
     2692            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    26942693               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    26952694            </td>
     
    29432942         clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
    29442943         experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
    2945          these problems. The problem was that some existing HTTP/1.0 clients may be sending Keep-Alive to a proxy server that doesn't
    2946          understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive
    2947          connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients
    2948          must be prevented from using Keep-Alive when talking to proxies.
     2944         these problems. The problem was that some existing HTTP/1.0 clients might send Keep-Alive to a proxy server that doesn't understand
     2945         Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection
     2946         and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented
     2947         from using Keep-Alive when talking to proxies.
    29492948      </p>
    29502949      <p id="rfc.section.B.2.p.2">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.
     
    29602959      </p>
    29612960      <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    2962          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
     2961         for transfer encoding that might not be self delimiting); it was important to straighten out exactly how message lengths are
    29632962         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body" title="Message Body">3.3</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
    29642963      </p>
     
    33883387      <p id="rfc.section.D.8.p.2">Partly resolved issues: </p>
    33893388      <ul>
    3390          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there may be methods for which a request body MUST NOT be included)
     3389         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there might be methods for which a request body MUST NOT be included)
    33913390         </li>
    33923391         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/163">http://tools.ietf.org/wg/httpbis/trac/ticket/163</a>&gt;: "editorial improvements around HTTP-date"
Note: See TracChangeset for help on using the changeset viewer.