Changeset 902 for draft-ietf-httpbis/latest
- Timestamp:
- 24/07/10 07:25:24 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r900 r902 382 382 <link rel="Chapter" title="6 Protocol Parameters" href="#rfc.section.6"> 383 383 <link rel="Chapter" title="7 Connections" href="#rfc.section.7"> 384 <link rel="Chapter" title="8 Miscellaneous notes that m aydisappear" href="#rfc.section.8">384 <link rel="Chapter" title="8 Miscellaneous notes that might disappear" href="#rfc.section.8"> 385 385 <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9"> 386 386 <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10"> … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 3">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-24"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: January 2 4, 2011</td>437 <td class="left">Expires: January 25, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">July 2 3, 2010</td>490 <td class="right">July 24, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 2 4, 2011.</p>518 <p>This Internet-Draft will expire in January 25, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 624 624 </ul> 625 625 </li> 626 <li class="tocline0">8. <a href="#misc">Miscellaneous notes that m aydisappear</a><ul class="toc">626 <li class="tocline0">8. <a href="#misc">Miscellaneous notes that might disappear</a><ul class="toc"> 627 627 <li class="tocline1">8.1 <a href="#scheme.aliases">Scheme aliases considered harmful</a></li> 628 628 <li class="tocline1">8.2 <a href="#http.proxy">Use of HTTP for proxy communication</a></li> … … 726 726 we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of 727 727 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 m ay act in parallel and perhaps at729 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. 730 730 </p> 731 731 <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, … … 808 808 </p> 809 809 </div> 810 <p id="rfc.section.1.2.2.p.3">The OWS rule is used where zero or more linear whitespace characters m ayappear. 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. 811 811 </p> 812 812 <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. … … 878 878 <div id="rfc.iref.o.1"></div> 879 879 <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 m ayact as a client on some connections and a server on others. We use the term "user agent" to refer to the880 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 881 881 program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server" 882 882 to refer to the program that can originate authoritative responses to a request. 883 883 </p> 884 884 <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 m ay be accomplished via a single bidirectional connection (===) between the user agent (UA) and the886 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). 887 887 </p> 888 888 <div id="rfc.figure.u.15"></div><pre class="drawing"> request > … … 921 921 </span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="intermediaries" href="#intermediaries">Intermediaries</a></h2> 922 922 <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 m ayact 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, 924 924 proxy, gateway, or tunnel, switching behavior based on the nature of each request. 925 925 </p> … … 928 928 < < < < 929 929 </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 m ayapply930 message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply 931 931 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 m ay 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 same934 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. 935 935 </p> 936 936 <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: … … 940 940 <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 941 941 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 m ayrequire translation942 Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation 943 943 to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests 944 944 through a common intermediary for the sake of security, annotation services, or shared caching. … … 953 953 </p> 954 954 <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 m ayhave been initiated by an HTTP request. A tunnel ceases to exist955 a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist 956 956 when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, 957 957 such as when transport-layer security is used to establish private communication through a shared firewall proxy. … … 959 959 <div id="rfc.iref.c.3"></div> 960 960 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <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. 965 964 </p> 966 965 <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 … … 972 971 < < 973 972 </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 m aybe additional constraints placed by the client or by the origin server on when973 Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when 975 974 that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are 976 975 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>. … … 990 989 the scope of this specification. 991 990 </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 m ay993 be used for one or more request/response exchanges, although connections m aybe closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 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 7.1</a>). 994 993 </p> 995 994 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="http.version" href="#http.version">HTTP Version</a></h2> … … 998 997 than the features obtained via that communication. No change is made to the version number for the addition of message components 999 998 which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented 1000 when the changes made to the protocol add features which do not change the general message parsing algorithm, but which m ay999 when the changes made to the protocol add features which do not change the general message parsing algorithm, but which might 1001 1000 add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format 1002 1001 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. … … 1020 1019 </p> 1021 1020 <div class="note" id="rfc.section.2.5.p.9"> 1022 <p> <b>Note:</b> Converting between versions of HTTP m ayinvolve 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. 1023 1022 </p> 1024 1023 </div> … … 1026 1025 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 1027 1026 <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 m ay be; it merely defines an interface that can be used to interact1029 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>. 1030 1029 </p> 1031 1030 <p id="rfc.section.2.6.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", … … 1063 1062 </p> 1064 1063 <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 m ay or may not exist and, even when it does exist, may or may not be running an HTTP server or listening to the indicated1066 port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish a naming authority1067 (whatever entity has the ability to place an HTTP server at that Internet name or address) and allows that authority to determine1068 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. 1069 1068 </p> 1070 1069 <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, … … 1074 1073 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1075 1074 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 m ayalso be used to provide access to "http" identified resources1075 an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources 1077 1076 --- it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1078 1077 </p> … … 1091 1090 <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> ] 1092 1091 </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 m aybe 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. 1094 1093 </p> 1095 1094 <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 … … 1136 1135 <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> 1137 1136 </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 m ay result in1139 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. 1140 1139 </p> 1141 1140 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1152 1151 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 1153 1152 is a superset of US-ASCII. Attempting to parse HTTP as a stream of Unicode characters in a character encoding like UTF-16 1154 m ayintroduce 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. 1155 1154 </p> 1156 1155 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.fields" href="#header.fields">Header Fields</a></h2> … … 1240 1239 </p> 1241 1240 <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 m ay indicate an attempt to perform request or response smuggling (bypass of security-related1243 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-coding1241 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 1244 1243 is decoded. 1245 1244 </p> … … 1304 1303 / <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> 1305 1304 </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 m aybe given the semantics of general header fields if all parties in the communication recognize1305 or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize 1307 1306 them to be general-header fields. Unrecognized header fields are treated as entity-header fields. 1308 1307 </p> … … 1547 1546 ; month day (e.g., Jun 2) 1548 1547 </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 m ayhave 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, 1550 1549 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1551 1550 </p> … … 1557 1556 </div> 1558 1557 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <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 m ay need to be applied to1560 a payload body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding1561 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. 1562 1561 </p> 1563 1562 <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 6.2.1</a> … … 1899 1898 </li> 1900 1899 </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 m aysend "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: 1902 1901 100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client 1903 1902 sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the … … 1968 1967 </li> 1969 1968 </ul> 1970 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="misc" href="#misc">Miscellaneous notes that m aydisappear</a></h1>1969 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="misc" href="#misc">Miscellaneous notes that might disappear</a></h1> 1971 1970 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h2> 1972 1971 <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> … … 2002 2001 field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a 2003 2002 connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional 2004 header field m aynot 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. 2005 2004 </p> 2006 2005 <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. … … 2105 2104 or not it is willing to accept trailer fields in a chunked transfer-coding. 2106 2105 </p> 2107 <p id="rfc.section.9.5.p.2">Its value m ayconsist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional2106 <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 2108 2107 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2109 2108 </p> … … 2614 2613 this problem. 2615 2614 </p> 2616 <p id="rfc.section.11.5.p.5">The judicious use of cryptography, when appropriate, m aysuffice to protect against a broad range of security and privacy2615 <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 2617 2616 attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification. 2618 2617 </p> … … 2679 2678 <tr> 2680 2679 <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 1950, May 1996.<br>RFC 1950 is an Informational RFC, thus it m aybe less stable than this specification. On the other hand, this downward reference2680 <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 1950, May 1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2682 2681 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>. 2683 2682 </td> … … 2685 2684 <tr> 2686 2685 <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 1951, May 1996.<br>RFC 1951 is an Informational RFC, thus it m aybe less stable than this specification. On the other hand, this downward reference2686 <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 1951, May 1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2688 2687 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>. 2689 2688 </td> … … 2691 2690 <tr> 2692 2691 <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 1952, May 1996.<br>RFC 1952 is an Informational RFC, thus it m aybe less stable than this specification. On the other hand, this downward reference2692 <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 1952, May 1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference 2694 2693 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>. 2695 2694 </td> … … 2943 2942 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 2944 2943 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 m ay be sending Keep-Alive to a proxy server that doesn't2946 understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive2947 connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients2948 must be preventedfrom 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. 2949 2948 </p> 2950 2949 <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. … … 2960 2959 </p> 2961 2960 <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 m aynot be self delimiting); it was important to straighten out exactly how message lengths are2961 for transfer encoding that might not be self delimiting); it was important to straighten out exactly how message lengths are 2963 2962 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>) 2964 2963 </p> … … 3388 3387 <p id="rfc.section.D.8.p.2">Partly resolved issues: </p> 3389 3388 <ul> 3390 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>>: "205 Bodies" (took out language that implied that there m aybe methods for which a request body MUST NOT be included)3389 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>>: "205 Bodies" (took out language that implied that there might be methods for which a request body MUST NOT be included) 3391 3390 </li> 3392 3391 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/163">http://tools.ietf.org/wg/httpbis/trac/ticket/163</a>>: "editorial improvements around HTTP-date" -
draft-ietf-httpbis/latest/p2-semantics.html
r900 r902 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 3">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-24"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 "HTTP/1.1" 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 2 4, 2011</td>436 <td class="left">Expires: January 25, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">July 2 3, 2010</td>489 <td class="right">July 24, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 2 4, 2011.</p>516 <p>This Internet-Draft will expire in January 25, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 928 928 </li> 929 929 <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 m aynot be).930 that it is a representation of the resource at the Content-Location URI (but it might not be). 931 931 </li> 932 932 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> … … 943 943 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 944 944 <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 themselves946 o r 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. 947 947 </p> 948 948 <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 … … 1296 1296 <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 1297 1297 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 m ay 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 useful1300 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). 1301 1301 </p> 1302 1302 <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. … … 1335 1335 <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 1336 1336 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 m ayerase the client's unacknowledged input buffers before they can be read and interpreted1337 a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted 1338 1338 by the HTTP application. 1339 1339 </p> … … 1384 1384 <div class="note" id="rfc.section.8.4.7.p.3"> 1385 1385 <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 m ay even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of1387 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. 1388 1388 </p> 1389 1389 </div> … … 1502 1502 </p> 1503 1503 <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 m ay wish1505 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. 1506 1506 </p> 1507 1507 </div> … … 1629 1629 <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> 1630 1630 <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 maybe 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> 1632 1632 <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). 1633 1633 </p> … … 2125 2125 has no better mechanism. 2126 2126 </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 7.8</a>) may expose information sent in request headers in theresponse. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect2127 <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 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 2128 2128 data from the client. 2129 2129 </p>
Note: See TracChangeset
for help on using the changeset viewer.