Ignore:
Timestamp:
24/07/10 07:25:24 (12 years ago)
Author:
fielding@…
Message:

regenerate html

Location:
draft-ietf-httpbis/latest
Files:
2 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"

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

    r900 r902  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-23">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 24, 2011</td>
     436               <td class="left">Expires: January 25, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 23, 2010</td>
     489               <td class="right">July 24, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 24, 2011.</p>
     516      <p>This Internet-Draft will expire in January 25, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    928928         </li>
    929929         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
    930             that it is a representation of the resource at the Content-Location URI (but it may not be).
     930            that it is a representation of the resource at the Content-Location URI (but it might not be).
    931931         </li>
    932932         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
    … …  
    943943      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
    944944      <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
    945          careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves
    946          or others.
     945         careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or
     946         others.
    947947      </p>
    948948      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
    … …  
    12961296      <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    12971297         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such
    1298          that the follow-on representation may be useful without implying that it adequately represents the previously requested resource.
    1299          Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful
    1300          description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
     1298         that the follow-on representation might be useful without implying that it adequately represents the previously requested
     1299         resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
     1300         be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
    13011301      </p>
    13021302      <p id="rfc.section.8.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
    … …  
    13351335      <p id="rfc.section.8.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    13361336         the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
    1337          a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted
     1337         a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
    13381338         by the HTTP application.
    13391339      </p>
    … …  
    13841384      <div class="note" id="rfc.section.8.4.7.p.3">
    13851385         <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
    1386             In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    1387             an incoming response to determine if it is acceptable.
     1386            In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the headers
     1387            of an incoming response to determine if it is acceptable.
    13881388         </p>
    13891389      </div>
    … …  
    15021502      </p>
    15031503      <div class="note" id="rfc.section.8.5.4.p.2">
    1504          <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish
    1505             to simply refuse the connection.
     1504         <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers might
     1505            wish to simply refuse the connection.
    15061506         </p>
    15071507      </div>
    … …  
    16291629      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
    16301630  <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    1631 </pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p>
     1631</pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    16321632      <p id="rfc.section.9.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    16331633      </p>
    … …  
    21252125         has no better mechanism.
    21262126      </p>
    2127       <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>) may expose information sent in request headers in the response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
     2127      <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request headers within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
    21282128         data from the client.
    21292129      </p>
Note: See TracChangeset for help on using the changeset viewer.