Changeset 1741 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 08/07/12 19:13:21 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1740 r1741 36 36 <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 37 37 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 <!ENTITY header-proxy-authenticate "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 38 40 <!ENTITY idempotent-methods "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 39 41 <!ENTITY methods "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 503 505 that wishes to interoperate with third-party HTTP servers &MUST; 504 506 conform to HTTP user agent requirements on the gateway's inbound 505 connection and &MUST; implement the Connection506 (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)507 header fields for both connections.507 connection and &MUST; implement the <x:ref>Connection</x:ref> 508 (<xref target="header.connection"/>) and <x:ref>Via</x:ref> 509 (<xref target="header.via"/>) header fields for both connections. 508 510 </t> 509 511 <t><iref primary="true" item="tunnel"/> … … 662 664 behavior of a recipient in the absence of such a field can change. 663 665 Unless specified otherwise, header fields defined in HTTP/1.1 are 664 defined for all versions of HTTP/1.x. In particular, the Host and 665 Connection header fields ought to be implemented by all HTTP/1.x 666 implementations whether or not they advertise conformance with HTTP/1.1. 666 defined for all versions of HTTP/1.x. In particular, the <x:ref>Host</x:ref> 667 and <x:ref>Connection</x:ref> header fields ought to be implemented by all 668 HTTP/1.x implementations whether or not they advertise conformance with 669 HTTP/1.1. 667 670 </t> 668 671 <t> … … 674 677 the message's HTTP version. An unrecognized header field received 675 678 by a proxy &MUST; be forwarded downstream unless the header field's 676 field-name is listed in the message's Connectionheader field679 field-name is listed in the message's <x:ref>Connection</x:ref> header field 677 680 (see <xref target="header.connection"/>). 678 681 These requirements allow HTTP's functionality to be enhanced without … … 1162 1165 to the procedures in &cons-new-header-fields;. 1163 1166 Unrecognized header fields &MUST; be forwarded by a proxy unless the 1164 field-name is listed in the Connectionheader field1167 field-name is listed in the <x:ref>Connection</x:ref> header field 1165 1168 (<xref target="header.connection"/>) or the proxy is specifically 1166 1169 configured to block or otherwise transform such fields. … … 1474 1477 <t> 1475 1478 The presence of a message body in a request is signaled by a 1476 a Content-Length or Transfer-Encoding header field.1477 Request message framing is independent of method semantics,1479 a <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header 1480 field. Request message framing is independent of method semantics, 1478 1481 even if the method does not define any use for a message body. 1479 1482 </t> … … 1483 1486 status code (<xref target="status-code"/>). 1484 1487 Responses to the HEAD request method never include a message body 1485 because the associated response header fields (e.g., Transfer-Encoding,1486 Content-Length, etc.) only indicate what their values would have been1487 i f the request method had been GET.1488 <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of1489 having a message body.1488 because the associated response header fields (e.g., 1489 <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only 1490 indicate what their values would have been if the request method had been 1491 GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel 1492 mode instead of having a message body. 1490 1493 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and 1491 1494 <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body. … … 1587 1590 <x:anchor-alias value="Content-Length"/> 1588 1591 <t> 1589 When a message does not have a Transfer-Encoding header field and the1590 payload body length can be determined prior to being transferred, a1592 When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field 1593 and the payload body length can be determined prior to being transferred, a 1591 1594 Content-Length header field &SHOULD; be sent to indicate the length of the 1592 1595 payload body that is either present as the message body, for requests … … 1657 1660 Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the 1658 1661 connection will become a tunnel immediately after the empty line that 1659 concludes the header fields. A client &MUST; ignore any Content-Length 1660 or Transfer-Encoding header fields received in such a message. 1662 concludes the header fields. A client &MUST; ignore any 1663 <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header 1664 fields received in such a message. 1661 1665 </t></x:lt> 1662 1666 <x:lt><t> 1663 If a Transfer-Encodingheader field is present1667 If a <x:ref>Transfer-Encoding</x:ref> header field is present 1664 1668 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>) 1665 1669 is the final encoding, the message body length is determined by reading … … 1668 1672 </t> 1669 1673 <t> 1670 If a Transfer-Encoding header field is present in a response and the1671 "chunked" transfer-coding is not the final encoding, the message body1672 length is determined by reading the connection until it is closed by1673 the server.1674 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a 1675 response and the "chunked" transfer-coding is not the final encoding, the 1676 message body length is determined by reading the connection until it is 1677 closed by the server. 1674 1678 If a Transfer-Encoding header field is present in a request and the 1675 1679 "chunked" transfer-coding is not the final encoding, the message body … … 1678 1682 </t> 1679 1683 <t> 1680 If a message is received with both a Transfer-Encoding header field1681 and a Content-Length header field, the Transfer-Encoding overrides1682 the Content-Length.1684 If a message is received with both a <x:ref>Transfer-Encoding</x:ref> 1685 and a <x:ref>Content-Length</x:ref> header field, the 1686 Transfer-Encoding overrides the Content-Length. 1683 1687 Such a message might indicate an attempt to perform request or response 1684 1688 smuggling (bypass of security-related checks on message routing or content) … … 1688 1692 </t></x:lt> 1689 1693 <x:lt><t> 1690 If a message is received without Transfer-Encoding and with either1691 multiple Content-Length header fields having differing field-values or1692 a single Content-Length header field having an invalid value, then the1693 message framing is invalid and &MUST; be treated as an error to1694 prevent request or response smuggling.1694 If a message is received without <x:ref>Transfer-Encoding</x:ref> and with 1695 either multiple <x:ref>Content-Length</x:ref> header fields having 1696 differing field-values or a single Content-Length header field having an 1697 invalid value, then the message framing is invalid and &MUST; be treated 1698 as an error to prevent request or response smuggling. 1695 1699 If this is a request message, the server &MUST; respond with 1696 1700 a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. … … 1702 1706 </t></x:lt> 1703 1707 <x:lt><t> 1704 If a valid Content-Length header field1705 is present without Transfer-Encoding, its decimal value defines the1708 If a valid <x:ref>Content-Length</x:ref> header field is present without 1709 <x:ref>Transfer-Encoding</x:ref>, its decimal value defines the 1706 1710 message body length in octets. If the actual number of octets sent in 1707 1711 the message is less than the indicated Content-Length, the recipient … … 1736 1740 <t> 1737 1741 A server &MAY; reject a request that contains a message body but 1738 not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>. 1742 not a <x:ref>Content-Length</x:ref> by responding with 1743 <x:ref>411 (Length Required)</x:ref>. 1739 1744 </t> 1740 1745 <t> 1741 1746 Unless a transfer-coding other than "chunked" has been applied, 1742 1747 a client that sends a request containing a message body &SHOULD; 1743 use a valid Content-Length header field if the message body length1744 is known in advance, rather than the "chunked" encoding, since some1748 use a valid <x:ref>Content-Length</x:ref> header field if the message body 1749 length is known in advance, rather than the "chunked" encoding, since some 1745 1750 existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref> 1746 1751 status code even though they understand the chunked encoding. This … … 1751 1756 <t> 1752 1757 A client that sends a request containing a message body &MUST; include a 1753 valid Content-Length header field if it does not know the server will1754 handle HTTP/1.1 (or later) requests; such knowledge can be in the form1755 of specific user configuration or by remembering the version of a prior1756 received response.1758 valid <x:ref>Content-Length</x:ref> header field if it does not know the 1759 server will handle HTTP/1.1 (or later) requests; such knowledge can be in 1760 the form of specific user configuration or by remembering the version of a 1761 prior received response. 1757 1762 </t> 1758 1763 </section> … … 1777 1782 A message body that uses the chunked transfer encoding is 1778 1783 incomplete if the zero-sized chunk that terminates the encoding has not 1779 been received. A message that uses a valid Content-Length is incomplete1780 i f the size of the message body received (in octets) is less than the1781 value given by Content-Length. A response that has neither chunked1784 been received. A message that uses a valid <x:ref>Content-Length</x:ref> is 1785 incomplete if the size of the message body received (in octets) is less than 1786 the value given by Content-Length. A response that has neither chunked 1782 1787 transfer encoding nor Content-Length is terminated by closure of the 1783 1788 connection, and thus is considered complete regardless of the number of … … 1866 1871 The HTTP Transfer Coding registry is defined in 1867 1872 <xref target="transfer.coding.registry"/>. 1868 HTTP/1.1 uses transfer-coding values in the TEheader field1869 (<xref target="header.te"/>) and in the Transfer-Encoding header field1870 (<xref target="header.transfer-encoding"/>).1873 HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field 1874 (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref> 1875 header field (<xref target="header.transfer-encoding"/>). 1871 1876 </t> 1872 1877 … … 1921 1926 <t> 1922 1927 The trailer allows the sender to include additional HTTP header 1923 fields at the end of the message. The Trailer header field can be1924 used to indicate which header fields are included in a trailer (see1928 fields at the end of the message. The <x:ref>Trailer</x:ref> header field 1929 can be used to indicate which header fields are included in a trailer (see 1925 1930 <xref target="header.trailer"/>). 1926 1931 </t> … … 1930 1935 true: 1931 1936 <list style="numbers"> 1932 <t>the request included a TE header field that indicates "trailers" is1933 acceptable in the transfer-coding of the response, as described in1934 <xref target="header.te"/>; or,</t>1937 <t>the request included a <x:ref>TE</x:ref> header field that indicates 1938 "trailers" is acceptable in the transfer-coding of the response, as 1939 described in <xref target="header.te"/>; or,</t> 1935 1940 1936 1941 <t>the trailer fields consist entirely of optional metadata, and the … … 2076 2081 <t> 2077 2082 The TE header field only applies to the immediate connection. 2078 Therefore, the keyword &MUST; be supplied within a Connection header 2079 field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. 2083 Therefore, the keyword &MUST; be supplied within a <x:ref>Connection</x:ref> 2084 header field (<xref target="header.connection"/>) whenever TE is present in 2085 an HTTP/1.1 message. 2080 2086 </t> 2081 2087 <t> … … 2120 2126 <x:anchor-alias value="qvalue"/> 2121 2127 <t> 2122 Both transfer codings ( TE request header field, <xref target="header.te"/>)2123 and content negotiation (&content.negotiation;) use short "floating point"2124 numbers to indicate the relative importance ("weight") of various2125 negotiable parameters. A weight is normalized to a real number in2126 the range 0 through 1, where 0 is the minimum and 1 the maximum2127 value. If a parameter has a quality value of 0, then content with2128 Both transfer codings (<x:ref>TE</x:ref> request header field, 2129 <xref target="header.te"/>) and content negotiation (&content.negotiation;) 2130 use short "floating point" numbers to indicate the relative importance 2131 ("weight") of various negotiable parameters. A weight is normalized to a 2132 real number in the range 0 through 1, where 0 is the minimum and 1 the 2133 maximum value. If a parameter has a quality value of 0, then content with 2128 2134 this parameter is "not acceptable" for the client. HTTP/1.1 2129 2135 applications &MUST-NOT; generate more than three digits after the … … 2171 2177 include the following header fields: 2172 2178 <list style="symbols"> 2173 <t> Transfer-Encoding</t>2174 <t> Content-Length</t>2175 <t> Trailer</t>2179 <t><x:ref>Transfer-Encoding</x:ref></t> 2180 <t><x:ref>Content-Length</x:ref></t> 2181 <t><x:ref>Trailer</x:ref></t> 2176 2182 </list> 2177 2183 </t> … … 2273 2279 If the target URI's path component is empty, then the client &MUST; send 2274 2280 "/" as the path within the origin-form of request-target. 2275 A Hostheader field is also sent, as defined in2281 A <x:ref>Host</x:ref> header field is also sent, as defined in 2276 2282 <xref target="header.host"/>, containing the target URI's 2277 2283 authority component (excluding any userinfo). … … 2428 2434 A server that receives an HTTP request message &MUST; reconstruct 2429 2435 the user agent's original target URI, based on the pieces of information 2430 learned from the request-target, Host, and connection context, in order2431 to identify the intended target resource and properly service the request.2432 The URI derived from this reconstruction process is referred to as the2433 "effective request URI".2436 learned from the request-target, <x:ref>Host</x:ref> header field, and 2437 connection context, in order to identify the intended target resource and 2438 properly service the request. The URI derived from this reconstruction 2439 process is referred to as the "effective request URI". 2434 2440 </t> 2435 2441 <t> … … 2449 2455 If the request-target is in authority-form, then the effective 2450 2456 request URI's authority component is the same as the request-target. 2451 Otherwise, if a Host header field is supplied with a non-empty field-value,2452 then the authority component is the same as the Host field-value.2453 Otherwise, the authority component is the concatenation of the default2454 host name configured for the server, a colon (":"), and the connection's2455 incoming TCP port number in decimal form.2457 Otherwise, if a <x:ref>Host</x:ref> header field is supplied with a 2458 non-empty field-value, then the authority component is the same as the 2459 Host field-value. Otherwise, the authority component is the concatenation of 2460 the default host name configured for the server, a colon (":"), and the 2461 connection's incoming TCP port number in decimal form. 2456 2462 </t> 2457 2463 <t> … … 2503 2509 <t> 2504 2510 An origin server that does not allow resources to differ by requested 2505 host &MAY; ignore the Host field-value and instead replace it with a2506 configured server name when constructing the effective request URI.2507 </t> 2508 <t> 2509 Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;2510 attempt to use heuristics (e.g., examination of the URI path for2511 host &MAY; ignore the <x:ref>Host</x:ref> field-value and instead replace it 2512 with a configured server name when constructing the effective request URI. 2513 </t> 2514 <t> 2515 Recipients of an HTTP/1.0 request that lacks a <x:ref>Host</x:ref> header 2516 field &MAY; attempt to use heuristics (e.g., examination of the URI path for 2511 2517 something unique to a particular host) in order to guess the 2512 2518 effective request URI's authority component. … … 2542 2548 <t> 2543 2549 Intermediaries that forward a message &MUST; implement the 2544 Connection header field as specified in <xref target="header.connection"/>. 2550 <x:ref>Connection</x:ref> header field as specified in 2551 <xref target="header.connection"/>. 2545 2552 </t> 2546 2553 … … 2569 2576 The following HTTP/1.1 header fields are hop-by-hop header fields: 2570 2577 <list style="symbols"> 2571 <t> Connection</t>2572 <t>Keep-Alive </t>2573 <t> Proxy-Authenticate</t>2574 <t> Proxy-Authorization</t>2575 <t> TE</t>2576 <t> Trailer</t>2577 <t> Transfer-Encoding</t>2578 <t> Upgrade</t>2578 <t><x:ref>Connection</x:ref></t> 2579 <t>Keep-Alive (<xref target="RFC2068" x:fmt="of" x:sec="19.7.1.1"/>)</t> 2580 <t><x:ref>Proxy-Authenticate</x:ref> (&header-proxy-authenticate;)</t> 2581 <t><x:ref>Proxy-Authorization</x:ref> (&header-proxy-authorization;)</t> 2582 <t><x:ref>TE</x:ref></t> 2583 <t><x:ref>Trailer</x:ref></t> 2584 <t><x:ref>Transfer-Encoding</x:ref></t> 2585 <t><x:ref>Upgrade</x:ref></t> 2579 2586 </list> 2580 2587 </t> … … 2583 2590 </t> 2584 2591 <t> 2585 Other hop-by-hop header fields &MUST; be listed in a Connection header field2586 (<xref target="header.connection"/>).2592 Other hop-by-hop header fields &MUST; be listed in a 2593 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>). 2587 2594 </t> 2588 2595 </section> … … 2930 2937 Persistent connections provide a mechanism by which a client and a 2931 2938 server can signal the close of a TCP connection. This signaling takes 2932 place using the Connection header field (<xref target="header.connection"/>). Once a close 2933 has been signaled, the client &MUST-NOT; send any more requests on that 2939 place using the <x:ref>Connection</x:ref> header field 2940 (<xref target="header.connection"/>). Once a close has been signaled, the 2941 client &MUST-NOT; send any more requests on that 2934 2942 connection. 2935 2943 </t> … … 2938 2946 <t> 2939 2947 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2940 maintain a persistent connection unless a Connection header field including2941 the connection option "close" was sent in the request. If the server2942 chooses to close the connection immediately after sending the2948 maintain a persistent connection unless a <x:ref>Connection</x:ref> header 2949 field including the connection option "close" was sent in the request. If 2950 the server chooses to close the connection immediately after sending the 2943 2951 response, it &SHOULD; send a Connection header field including the 2944 2952 connection option "close". … … 2947 2955 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2948 2956 decide to keep it open based on whether the response from a server 2949 contains a Connection header field with the connection option "close". In case2950 the client does not want to maintain a connection for more than that2951 request, it &SHOULD; send a Connection header field including the2957 contains a <x:ref>Connection</x:ref> header field with the connection option 2958 "close". In case the client does not want to maintain a connection for more 2959 than that request, it &SHOULD; send a Connection header field including the 2952 2960 connection option "close". 2953 2961 </t> 2954 2962 <t> 2955 2963 If either the client or the server sends the "close" option in the 2956 Connection header field, that request becomes the last one for the2957 connection.2964 <x:ref>Connection</x:ref> header field, that request becomes the last one 2965 for the connection. 2958 2966 </t> 2959 2967 <t> … … 3273 3281 <t> 3274 3282 The Upgrade header field only applies to the immediate connection. 3275 Therefore, the upgrade keyword &MUST; be supplied within a Connection3276 header field (<xref target="header.connection"/>) whenever Upgrade is present in an3277 HTTP/1.1 message.3283 Therefore, the upgrade keyword &MUST; be supplied within a 3284 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>) 3285 whenever Upgrade is present in an HTTP/1.1 message. 3278 3286 </t> 3279 3287 <t> … … 3376 3384 Furthermore, the header field-name "Close" shall be registered as 3377 3385 "reserved", since using that name as an HTTP header field might 3378 conflict with the "close" connection option of the " Connection"3386 conflict with the "close" connection option of the "<x:ref>Connection</x:ref>" 3379 3387 header field (<xref target="header.connection"/>). 3380 3388 </t> … … 3639 3647 <t> 3640 3648 The HTTP Upgrade Token Registry defines the name space for protocol-name 3641 tokens used to identify protocols in the Upgrade header field.3642 Each registered protocol-name is associated with contact information and3643 an optional set of specifications that details how the connection3649 tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header 3650 field. Each registered protocol name is associated with contact information 3651 and an optional set of specifications that details how the connection 3644 3652 will be processed after it has been upgraded. 3645 3653 </t> … … 4222 4230 </reference> 4223 4231 4232 <reference anchor="Part7"> 4233 <front> 4234 <title>HTTP/1.1, part 7: Authentication</title> 4235 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> 4236 <organization abbrev="Adobe">Adobe Systems Incorporated</organization> 4237 <address><email>fielding@gbiv.com</email></address> 4238 </author> 4239 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> 4240 <organization abbrev="W3C">World Wide Web Consortium</organization> 4241 <address><email>ylafon@w3.org</email></address> 4242 </author> 4243 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> 4244 <organization abbrev="greenbytes">greenbytes GmbH</organization> 4245 <address><email>julian.reschke@greenbytes.de</email></address> 4246 </author> 4247 <date month="&ID-MONTH;" year="&ID-YEAR;"/> 4248 </front> 4249 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/> 4250 <x:source href="p7-auth.xml" basename="p7-auth"> 4251 <x:defines>Proxy-Authenticate</x:defines> 4252 <x:defines>Proxy-Authorization</x:defines> 4253 </x:source> 4254 </reference> 4255 4224 4256 <reference anchor="RFC5234"> 4225 4257 <front> … … 4833 4865 Since HTTP/0.9 did not support header fields in a request, 4834 4866 there is no mechanism for it to support name-based virtual 4835 hosts (selection of resource by inspection of the Hostheader4867 hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header 4836 4868 field). Any server that implements name-based virtual hosts 4837 4869 ought to disable support for HTTP/0.9. Most requests that … … 4850 4882 <section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4851 4883 <t> 4852 The requirements that clients and servers support the Host header4853 field (<xref target="header.host"/>), report an error if it is4884 The requirements that clients and servers support the <x:ref>Host</x:ref> 4885 header field (<xref target="header.host"/>), report an error if it is 4854 4886 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4855 4887 are among the most important changes defined by HTTP/1.1. … … 4859 4891 addresses and servers; there was no other established mechanism for 4860 4892 distinguishing the intended server of a request than the IP address 4861 to which that request was directed. The Hostheader field was4893 to which that request was directed. The <x:ref>Host</x:ref> header field was 4862 4894 introduced during the development of HTTP/1.1 and, though it was 4863 4895 quickly implemented by most HTTP/1.0 browsers, additional requirements … … 4881 4913 with a "Connection: keep-alive" request header field. However, some 4882 4914 experimental implementations of HTTP/1.0 persistent connections are faulty; 4883 for example, if a HTTP/1.0 proxy server doesn't understand Connection, it4884 will erroneously forward that header to the next inbound server, which4885 would result in a hung connection.4915 for example, if a HTTP/1.0 proxy server doesn't understand 4916 <x:ref>Connection</x:ref>, it will erroneously forward that header to the 4917 next inbound server, which would result in a hung connection. 4886 4918 </t> 4887 4919 <t> … … 4942 4974 </t> 4943 4975 <t> 4944 Require recipients to handle bogus Content-Length header fields as errors. 4976 Require recipients to handle bogus <x:ref>Content-Length</x:ref> header 4977 fields as errors. 4945 4978 (<xref target="message.body"/>) 4946 4979 </t> … … 4980 5013 </t> 4981 5014 <t> 4982 Define the semantics of the "Upgrade" header field in responses other than4983 101 (this was incorporated from <xref target="RFC2817"/>).5015 Define the semantics of the <x:ref>Upgrade</x:ref> header field in responses 5016 other than 101 (this was incorporated from <xref target="RFC2817"/>). 4984 5017 (<xref target="header.upgrade"/>) 4985 5018 </t>
Note: See TracChangeset
for help on using the changeset viewer.