Changeset 1863 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 04/09/12 08:58:08 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1861 r1863 1267 1267 </t> 1268 1268 <t anchor="rule.BWS"> 1269 BWS is used where the grammar allows optional whitespace for historical1270 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.11269 BWS is used where the grammar allows optional whitespace, for historical 1270 reasons, but senders &SHOULD-NOT; produce it in messages; 1271 1271 recipients &MUST; accept such bad optional whitespace and remove it before 1272 1272 interpreting the field value or forwarding the message downstream. … … 1356 1356 <x:anchor-alias value="special"/> 1357 1357 <x:anchor-alias value="word"/> 1358 Many HTTP /1.1header field values consist of words (token or quoted-string)1358 Many HTTP header field values consist of words (token or quoted-string) 1359 1359 separated by whitespace or special characters. These special characters 1360 1360 &MUST; be in a quoted string to be used within a parameter value (as defined … … 1741 1741 Request messages that are prematurely terminated, possibly due to a 1742 1742 canceled connection or a server-imposed time-out exception, &MUST; 1743 result in closure of the connection; sending an HTTP/1.1error response1743 result in closure of the connection; sending an error response 1744 1744 prior to closing the connection is &OPTIONAL;. 1745 1745 </t> … … 1841 1841 </artwork></figure> 1842 1842 <t> 1843 All transfer-coding values are case-insensitive .1844 The HTTP Transfer Coding registry is defined in1843 All transfer-coding values are case-insensitive and &SHOULD; be registered 1844 within the HTTP Transfer Coding registry, as defined in 1845 1845 <xref target="transfer.coding.registry"/>. 1846 HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field1847 (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref>1848 header field (<xref target="header.transfer-encoding"/>).1846 They are used in the <x:ref>TE</x:ref> (<xref target="header.te"/>) and 1847 <x:ref>Transfer-Encoding</x:ref> (<xref target="header.transfer-encoding"/>) 1848 header fields. 1849 1849 </t> 1850 1850 … … 1980 1980 </artwork></figure> 1981 1981 <t> 1982 All HTTP/1.1 applications &MUST; be able to receive and decode the1982 All recipients &MUST; be able to receive and decode the 1983 1983 "chunked" transfer-coding and &MUST; ignore chunk-ext extensions 1984 1984 they do not understand. … … 2324 2324 </t> 2325 2325 <t> 2326 When a n HTTP/1.1proxy receives a request with an absolute-form of2326 When a proxy receives a request with an absolute-form of 2327 2327 request-target, the proxy &MUST; ignore the received 2328 2328 Host header field (if any) and instead replace it with the host … … 2678 2678 <iref primary="true" item="Connection header field" x:for-anchor=""/> 2679 2679 <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/> 2680 <iref primary="true" item="close" x:for-anchor=""/> 2680 2681 <x:anchor-alias value="Connection"/> 2681 2682 <x:anchor-alias value="connection-option"/> … … 2715 2716 </artwork></figure> 2716 2717 <t> 2717 Connection options are c ompared case-insensitively.2718 Connection options are case-insensitive. 2718 2719 </t> 2719 2720 <t> … … 2747 2748 </t> 2748 2749 <t> 2749 HTTP/1.1 defines the "<x:dfn>close</x:dfn>" connection option for the2750 The "<x:dfn>close</x:dfn>" connection option is defined for a 2750 2751 sender to signal that this connection will be closed after completion of 2751 2752 the response. For example, … … 2757 2758 in either the request or the response header fields indicates that 2758 2759 the connection &SHOULD; be closed after the current request/response 2759 is complete (<xref target="persistent. connections"/>).2760 </t> 2761 <t> 2762 A n HTTP/1.1client that does not support persistent connections &MUST;2763 includethe "close" connection option in every request message.2764 </t> 2765 <t> 2766 A n HTTP/1.1server that does not support persistent connections &MUST;2767 includethe "close" connection option in every response message that2760 is complete (<xref target="persistent.tear-down"/>). 2761 </t> 2762 <t> 2763 A client that does not support persistent connections &MUST; 2764 send the "close" connection option in every request message. 2765 </t> 2766 <t> 2767 A server that does not support persistent connections &MUST; 2768 send the "close" connection option in every response message that 2768 2769 does not have a <x:ref>1xx (Informational)</x:ref> status code. 2769 2770 </t> … … 2827 2828 <section title="Establishment" anchor="persistent.establishment"> 2828 2829 <t> 2830 It is beyond the scope of this specification to describe how connections 2831 are established via various transport or session-layer protocols. 2829 2832 Each connection applies to only one transport link. 2830 2833 </t> 2831 2834 <t> 2832 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2833 maintain a persistent connection unless a <x:ref>Connection</x:ref> header 2834 field including the connection option "close" was sent in the request. 2835 </t> 2836 <t> 2837 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2838 decide to keep it open based on whether the response from a server 2839 contains a <x:ref>Connection</x:ref> header field with the connection option 2840 "close". 2841 </t> 2842 <t> 2843 Clients and servers &SHOULD-NOT; assume that a persistent connection is 2844 maintained for HTTP versions less than 1.1 unless it is explicitly 2845 signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward 2846 compatibility with HTTP/1.0 clients. 2847 </t> 2848 <t> 2849 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 2850 with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> 2851 for information and discussion of the problems with the Keep-Alive header field 2835 A recipient determines whether a connection is persistent or not based on 2836 the most recently received message's protocol version and 2837 <x:ref>Connection</x:ref> header field (if any): 2838 <list style="symbols"> 2839 <t>If the <x:ref>close</x:ref> connection option is present, the 2840 connection will not persist after the current response; else,</t> 2841 <t>If the received protocol is HTTP/1.1 (or later), the connection will 2842 persist after the current response; else,</t> 2843 <t>If the received protocol is HTTP/1.0, the "keep-alive" 2844 connection option is present, the recipient is not a proxy, and 2845 the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, 2846 the connection will persist after the current response; otherwise,</t> 2847 <t>The connection will close after the current response.</t> 2848 </list> 2849 </t> 2850 <t> 2851 A proxy server &MUST-NOT; maintain a persistent connection with an 2852 HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for 2853 information and discussion of the problems with the Keep-Alive header field 2852 2854 implemented by many HTTP/1.0 clients). 2853 2855 </t> … … 2856 2858 <section title="Reuse" anchor="persistent.reuse"> 2857 2859 <t> 2858 Unless otherwise indicated, the client 2859 &SHOULD; assume that the server will maintain a persistent connection, 2860 even after error responses from the server. 2861 </t> 2862 <t> 2863 In order to remain persistent, all messages on the connection &MUST; 2860 In order to remain persistent, all messages on a connection &MUST; 2864 2861 have a self-defined message length (i.e., one not defined by closure 2865 2862 of the connection), as described in <xref target="message.body"/>. 2863 </t> 2864 <t> 2865 A server &MAY; assume that an HTTP/1.1 client intends to maintain a 2866 persistent connection until a <x:ref>close</x:ref> connection option 2867 is received in a request. 2868 </t> 2869 <t> 2870 A client &MAY; reuse a persistent connection until it sends or receives 2871 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response 2872 without a "keep-alive" connection option. 2873 </t> 2874 <t> 2875 Clients and servers &SHOULD-NOT; assume that a persistent connection is 2876 maintained for HTTP versions less than 1.1 unless it is explicitly 2877 signaled. 2878 See <xref target="compatibility.with.http.1.0.persistent.connections"/> 2879 for more information on backward compatibility with HTTP/1.0 clients. 2866 2880 </t> 2867 2881 … … 2911 2925 <section title="Concurrency" anchor="persistent.concurrency"> 2912 2926 <t> 2913 Clients (including proxies)&SHOULD; limit the number of simultaneous2914 connections that they maintain to a given server (including proxies).2927 Clients &SHOULD; limit the number of simultaneous 2928 connections that they maintain to a given server. 2915 2929 </t> 2916 2930 <t> … … 2922 2936 </t> 2923 2937 <t> 2924 In particular, while using multiple connections avoidsthe "head-of-line2925 blocking" problem (wherebya request that takes significant server-side2926 processing and/or has a large payload can blocksubsequent requests on the2927 same connection ), each connection used consumes server resources (sometimes2928 significantly), and furthermore using multiple connections can cause2929 undesirable side effectsin congested networks.2938 Multiple connections are typically used to avoid the "head-of-line 2939 blocking" problem, wherein a request that takes significant server-side 2940 processing and/or has a large payload blocks subsequent requests on the 2941 same connection. However, each connection consumes server resources. 2942 Furthermore, using multiple connections can cause undesirable side effects 2943 in congested networks. 2930 2944 </t> 2931 2945 <t> … … 2961 2975 </t> 2962 2976 <t> 2963 HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's2964 flow control mechanisms to resolve temporary overloads, rather than2965 t erminatingconnections with the expectation that clients will retry.2977 Servers &SHOULD; maintain persistent connections and allow the underlying 2978 transport's flow control mechanisms to resolve temporary overloads, rather 2979 than terminate connections with the expectation that clients will retry. 2966 2980 The latter technique can exacerbate network congestion. 2967 2981 </t> 2968 2982 <t> 2969 A n HTTP/1.1 (or later)client sending a message body &SHOULD; monitor2983 A client sending a message body &SHOULD; monitor 2970 2984 the network connection for an error status code while it is transmitting 2971 2985 the request. If the client sees an error status code, it &SHOULD; … … 2975 2989 2976 2990 <section title="Tear-down" anchor="persistent.tear-down"> 2977 <t> 2978 Persistent connections provide a mechanism by which a client and a 2979 server can signal the close of a TCP connection. This signaling takes 2980 place using the <x:ref>Connection</x:ref> header field 2981 (<xref target="header.connection"/>). Once a close has been signaled, the 2982 client &MUST-NOT; send any more requests on that 2983 connection. 2984 </t> 2985 <t> 2986 If either the client or the server sends the "close" option in the 2987 <x:ref>Connection</x:ref> header field, that request/response pair 2988 becomes the last one for the connection. 2989 </t> 2990 <t> 2991 If the server chooses to close the connection immediately after sending the 2992 response, it &SHOULD; send a Connection header field including the 2993 connection option "close". 2994 </t> 2995 <t> 2996 In case the client does not want to maintain a connection for more 2997 than that request, it &SHOULD; send a Connection header field including the 2998 connection option "close". 2999 </t> 3000 <t> 3001 If the client is sending data, a server implementation using TCP 3002 &SHOULD; be careful to ensure that the client acknowledges receipt of 3003 the packet(s) containing the response, before the server closes the 3004 input connection. If the client continues sending data to the server 3005 after the close, the server's TCP stack will send a reset packet to 3006 the client, which might erase the client's unacknowledged input buffers 3007 before they can be read and interpreted by the HTTP application. 2991 <iref primary="false" item="Connection header field" x:for-anchor=""/> 2992 <iref primary="false" item="close" x:for-anchor=""/> 2993 <t> 2994 The <x:ref>Connection</x:ref> header field 2995 (<xref target="header.connection"/>) provides a "<x:ref>close</x:ref>" 2996 connection option that a sender &SHOULD; send when it wishes to close 2997 the connection after the current request/response pair. 2998 </t> 2999 <t> 3000 A client that sends a <x:ref>close</x:ref> connection option &MUST-NOT; 3001 send further requests on that connection (after the one containing 3002 <x:ref>close</x:ref>) and &MUST; close the connection after reading the 3003 final response message corresponding to this request. 3004 </t> 3005 <t> 3006 A server that receives a <x:ref>close</x:ref> connection option &MUST; 3007 initiate a lingering close of the connection after it sends the final 3008 response to the request that contained <x:ref>close</x:ref>. 3009 The server &SHOULD; include a <x:ref>close</x:ref> connection option 3010 in its final response on that connection. The server &MUST-NOT; process 3011 any further requests received on that connection. 3012 </t> 3013 <t> 3014 A server that sends a <x:ref>close</x:ref> connection option &MUST; 3015 initiate a lingering close of the connection after it sends the 3016 response containing <x:ref>close</x:ref>. The server &MUST-NOT; process 3017 any further requests received on that connection. 3018 </t> 3019 <t> 3020 A client that receives a <x:ref>close</x:ref> connection option &MUST; 3021 cease sending requests on that connection and close the connection 3022 after reading the response message containing the close; if additional 3023 pipelined requests had been sent on the connection, the client &SHOULD; 3024 assume that they will not be processed by the server. 3025 </t> 3026 <t> 3027 If a server performs an immediate close of a TCP connection, there is a 3028 significant risk that the client will not be able to read the last HTTP 3029 response. If the server receives additional data from the client on a 3030 fully-closed connection, such as another request that was sent by the 3031 client before receiving the server's response, the server's TCP stack will 3032 send a reset packet to the client; unfortunately, the reset packet might 3033 erase the client's unacknowledged input buffers before they can be read 3034 and interpreted by the client's HTTP parser. 3035 </t> 3036 <t> 3037 To avoid the TCP reset problem, a server can perform a lingering close on a 3038 connection by closing only the write side of the read/write connection 3039 (a half-close) and continuing to read from the connection until the 3040 connection is closed by the client or the server is reasonably certain 3041 that its own TCP stack has received the client's acknowledgement of the 3042 packet(s) containing the server's last response. It is then safe for the 3043 server to fully close the connection. 3044 </t> 3045 <t> 3046 It is unknown whether the reset problem is exclusive to TCP or might also 3047 be found in other transport connection protocols. 3008 3048 </t> 3009 3049 </section> … … 3018 3058 <x:anchor-alias value="protocol-version"/> 3019 3059 <t> 3020 The "Upgrade" header field allows the client to specify what 3021 additional communication protocols it would like to use, if the server 3022 chooses to switch protocols. Servers can use it to indicate what protocols 3023 they are willing to switch to. 3060 The "Upgrade" header field is intended to provide a simple mechanism 3061 for transitioning from HTTP/1.1 to some other protocol on the same 3062 connection. A client &MAY; send a list of protocols in the Upgrade 3063 header field of a request to invite the server to switch to one or 3064 more of those protocols before sending the final response. 3065 A server &MUST; send an Upgrade header field in <x:ref>101 (Switching 3066 Protocols)</x:ref> responses to indicate which protocol(s) are being 3067 switched to, and &MUST; send it in <x:ref>426 (Upgrade Required)</x:ref> 3068 responses to indicate acceptable protocols. 3069 A server &MAY; send an Upgrade header field in any other response to 3070 indicate that they might be willing to upgrade to one of the 3071 specified protocols for a future request. 3024 3072 </t> 3025 3073 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> … … 3037 3085 </artwork></figure> 3038 3086 <t> 3039 The Upgrade header field is intended to provide a simple mechanism 3040 for transitioning from HTTP/1.1 to some other, incompatible protocol. It 3041 does so by allowing the client to advertise its desire to use another 3042 protocol, such as a later version of HTTP with a higher major version 3043 number, even though the current request has been made using HTTP/1.1. 3044 This eases the difficult transition between incompatible protocols by 3087 Upgrade eases the difficult transition between incompatible protocols by 3045 3088 allowing the client to initiate a request in the more commonly 3046 3089 supported protocol while indicating to the server that it would like … … 3050 3093 </t> 3051 3094 <t> 3052 The Upgrade header field only applies to switching application-layer 3053 protocols upon the existing transport-layer connection. Upgrade 3054 cannot be used to insist on a protocol change; its acceptance and use 3055 by the server is optional. The capabilities and nature of the 3095 Upgrade cannot be used to insist on a protocol change; its acceptance and 3096 use by the server is optional. The capabilities and nature of the 3056 3097 application-layer communication after the protocol change is entirely 3057 3098 dependent upon the new protocol chosen, although the first action 3058 3099 after changing the protocol &MUST; be a response to the initial HTTP 3059 request containing the Upgrade header field. 3060 </t> 3061 <t> 3062 The Upgrade header field only applies to the immediate connection. 3063 Therefore, the upgrade keyword &MUST; be supplied within a 3100 request that contained the Upgrade header field. 3101 </t> 3102 <t> 3103 For example, if the Upgrade header field is received in a GET request 3104 and the server decides to switch protocols, then it &MUST; first respond 3105 with a <x:ref>101 (Switching Protocols)</x:ref> message in HTTP/1.1 and 3106 then immediately follow that with the new protocol's equivalent of a 3107 response to a GET on the target resource. This allows a connection to be 3108 upgraded to protocols with the same semantics as HTTP without the 3109 latency cost of an additional round-trip. A server &MUST-NOT; switch 3110 protocols unless the received message semantics can be honored by the new 3111 protocol; an OPTIONS request can be honored by any protocol. 3112 </t> 3113 <t> 3114 When Upgrade is sent, a sender &MUST; also send a 3064 3115 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>) 3065 whenever Upgrade is present in an HTTP/1.1 message. 3066 </t> 3067 <t> 3068 The Upgrade header field cannot be used to indicate a switch to a 3069 protocol on a different connection. For that purpose, it is more 3070 appropriate to use a <x:ref>3xx (Redirection)</x:ref> response (&status-3xx;). 3071 </t> 3072 <t> 3073 Servers &MUST; include the "Upgrade" header field in <x:ref>101 (Switching 3074 Protocols)</x:ref> responses to indicate which protocol(s) are being switched to, 3075 and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate 3076 acceptable protocols to upgrade to. Servers &MAY; include it in any other 3077 response to indicate that they are willing to upgrade to one of the 3078 specified protocols. 3116 that contains the "upgrade" connection option, in order to prevent Upgrade 3117 from being accidentally forwarded by intermediaries that might not implement 3118 the listed protocols. A server &MUST; ignore an Upgrade header field that 3119 is received in an HTTP/1.0 request. 3120 </t> 3121 <t> 3122 The Upgrade header field only applies to switching application-layer 3123 protocols on the existing transport-layer connection; it cannot be used 3124 to switch to a protocol on a different connection. For that purpose, it is 3125 more appropriate to use a <x:ref>3xx (Redirection)</x:ref> response 3126 (&status-3xx;). 3079 3127 </t> 3080 3128 <t> … … 3086 3134 </t> 3087 3135 </section> 3088 3089 3136 </section> 3090 3137
Note: See TracChangeset
for help on using the changeset viewer.