Changeset 2071 for draft-ietf-httpbis
- Timestamp:
- 31/12/12 06:09:31 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2070 r2071 1338 1338 </p> 1339 1339 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1340 status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1340 status code (<a href="#status.line" title="Status Line">Section 3.1.2</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero 1341 length. 1341 1342 </p> 1342 1343 <div id="rfc.iref.t.4"></div> … … 1935 1936 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 1936 1937 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> 1937 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 1938 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1938 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1939 1939 </p> 1940 1940 <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header … … 2043 2043 <p id="rfc.section.6.6.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2044 2044 </p> 2045 <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> includea <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection.2045 <p id="rfc.section.6.6.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close (see below) of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> send a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2046 2046 </p> 2047 2047 <p id="rfc.section.6.6.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. -
draft-ietf-httpbis/latest/p1-messaging.xml
r2070 r2071 1466 1466 mode instead of having a message body (&CONNECT;). 1467 1467 All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and 1468 <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT;include a message body.1468 <x:ref>304 (Not Modified)</x:ref> responses do not include a message body. 1469 1469 All other responses do include a message body, although the body 1470 &MAY;be of zero length.1470 might be of zero length. 1471 1471 </t> 1472 1472 … … 2718 2718 </t> 2719 2719 <t> 2720 A sender &MUST-NOT; include field-names in the Connectionheader2721 field -value for fields that are defined as expressing constraints2722 for all recipients in the request or response chain, such as the2723 Cache-Control header field(&header-cache-control;).2720 A sender &MUST-NOT; send a connection option corresponding to a header 2721 field that is intended for all recipients of the payload. 2722 For example, <x:ref>Cache-Control</x:ref> is never appropriate as a 2723 connection option (&header-cache-control;). 2724 2724 </t> 2725 2725 <t> … … 2966 2966 initiate a lingering close (see below) of the connection after it sends the 2967 2967 final response to the request that contained <x:ref>close</x:ref>. 2968 The server &SHOULD; includea <x:ref>close</x:ref> connection option2968 The server &SHOULD; send a <x:ref>close</x:ref> connection option 2969 2969 in its final response on that connection. The server &MUST-NOT; process 2970 2970 any further requests received on that connection. … … 3998 3998 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/> 3999 3999 <x:source href="p6-cache.xml" basename="p6-cache"> 4000 <x:defines>Cache-Control</x:defines> 4000 4001 <x:defines>Expires</x:defines> 4001 4002 </x:source> -
draft-ietf-httpbis/latest/p2-semantics.html
r2070 r2071 960 960 </p> 961 961 <div id="rfc.figure.u.6"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 962 </pre><p id="rfc.section.3.1.1.5.p.5">A sender <em class="bcp14">SHOULD</em> include a Content-Type header field in a message containing a payload body, defining the media type of the enclosed representation,963 unless the intended media type is unknownto the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the representation data to determine its type.962 </pre><p id="rfc.section.3.1.1.5.p.5">A sender that generates a message containing a payload body <em class="bcp14">SHOULD</em> generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown 963 to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the representation data to determine its type. 964 964 </p> 965 965 <p id="rfc.section.3.1.1.5.p.6">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for … … 1591 1591 <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h3> 1592 1592 <div id="rfc.iref.t.1"></div> 1593 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1.1</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1594 </p> 1595 <p id="rfc.section.4.3.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1596 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1593 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1.1</a>). 1594 </p> 1595 <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request. 1596 </p> 1597 <p id="rfc.section.4.3.8.p.3">A client <em class="bcp14">MUST NOT</em> send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would 1598 be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient <em class="bcp14">SHOULD</em> exclude any request header fields from the response body that are likely to contain sensitive data. 1599 </p> 1600 <p id="rfc.section.4.3.8.p.4">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1601 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1597 1602 messages in an infinite loop. 1598 1603 </p> 1599 <p id="rfc.section.4.3.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1600 </p> 1604 <p id="rfc.section.4.3.8.p.5">Responses to the TRACE method are not cacheable.</p> 1601 1605 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> 1602 1606 <p id="rfc.section.5.p.1">A client sends request header fields to provide more information about the request context, make the request conditional based … … 2006 2010 <tr> 2007 2011 <td class="left">Authorization</td> 2008 <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7. 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>2012 <td class="left"><a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 2009 2013 </tr> 2010 2014 <tr> 2011 2015 <td class="left">Proxy-Authorization</td> 2012 <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7. 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>2016 <td class="left"><a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 2013 2017 </tr> 2014 2018 </tbody> … … 2133 2137 </ul> 2134 2138 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> 2135 <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7. 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the2139 <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the 2136 2140 protocol. 2137 2141 </p> … … 2234 2238 <td class="left">401</td> 2235 2239 <td class="left">Unauthorized</td> 2236 <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7. 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>2240 <td id="status.401" class="left"><a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 2237 2241 </tr> 2238 2242 <tr> … … 2264 2268 <td class="left">407</td> 2265 2269 <td class="left">Proxy Authentication Required</td> 2266 <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7. 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>2270 <td id="status.407" class="left"><a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 2267 2271 </tr> 2268 2272 <tr> … … 3030 3034 <tr> 3031 3035 <td class="left">WWW-Authenticate</td> 3032 <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7. 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>3036 <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 3033 3037 </tr> 3034 3038 <tr> 3035 3039 <td class="left">Proxy-Authenticate</td> 3036 <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7. 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>3040 <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 3037 3041 </tr> 3038 3042 </tbody> … … 3928 3932 <h2 id="rfc.references.2"><a href="#rfc.section.11.2" id="rfc.section.11.2">11.2</a> Informative References 3929 3933 </h2> 3930 <table> 3934 <table> 3931 3935 <tr> 3932 3936 <td class="reference"><b id="BCP13">[BCP13]</b></td> … … 4022 4026 <td class="reference"><b id="RFC6151">[RFC6151]</b></td> 4023 4027 <td class="top">Turner, S. and L. Chen, “<a href="http://tools.ietf.org/html/rfc6151">Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</a>”, RFC 6151, March 2011. 4028 </td> 4029 </tr> 4030 <tr> 4031 <td class="reference"><b id="RFC6265">[RFC6265]</b></td> 4032 <td class="top"><a href="mailto:abarth@eecs.berkeley.edu" title="
 University of California, Berkeley
 ">Barth, A.</a>, “<a href="http://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a>”, RFC 6265, April 2011. 4024 4033 </td> 4025 4034 </tr> … … 4586 4595 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 4587 4596 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li> 4588 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.1 7">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li>4597 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li> 4589 4598 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.23">6.3.4</a></li> 4590 4599 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li> 4591 4600 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.27">6.5.15</a></li> 4592 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.1 8">4.3.8</a></li>4601 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.17">4.3.8</a></li> 4593 4602 <li><em>Section 9</em> <a href="#rfc.xref.Part1.43">10</a></li> 4594 4603 <li><em>Appendix B</em> <a href="#rfc.xref.Part1.32">8.3.1</a></li> … … 4628 4637 </ul> 4629 4638 </li> 4630 <li><em>Part7</em> <a href="#rfc.xref.Part7.1"> 5.4</a>, <a href="#rfc.xref.Part7.2">5.4</a>, <a href="#rfc.xref.Part7.3">6.1</a>, <a href="#rfc.xref.Part7.4">6.1</a>, <a href="#rfc.xref.Part7.5">6.1</a>, <a href="#rfc.xref.Part7.6">7.3</a>, <a href="#rfc.xref.Part7.7">7.3</a>, <a href="#Part7"><b>11.1</b></a><ul>4631 <li><em>Section 3</em> <a href="#rfc.xref.Part7. 3">6.1</a></li>4632 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7. 4">6.1</a></li>4633 <li><em>Section 3.2</em> <a href="#rfc.xref.Part7. 5">6.1</a></li>4634 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7. 1">5.4</a></li>4635 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7. 7">7.3</a></li>4636 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7. 2">5.4</a></li>4637 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7. 6">7.3</a></li>4639 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">4.3.8</a>, <a href="#rfc.xref.Part7.2">5.4</a>, <a href="#rfc.xref.Part7.3">5.4</a>, <a href="#rfc.xref.Part7.4">6.1</a>, <a href="#rfc.xref.Part7.5">6.1</a>, <a href="#rfc.xref.Part7.6">6.1</a>, <a href="#rfc.xref.Part7.7">7.3</a>, <a href="#rfc.xref.Part7.8">7.3</a>, <a href="#Part7"><b>11.1</b></a><ul> 4640 <li><em>Section 3</em> <a href="#rfc.xref.Part7.4">6.1</a></li> 4641 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.5">6.1</a></li> 4642 <li><em>Section 3.2</em> <a href="#rfc.xref.Part7.6">6.1</a></li> 4643 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.2">5.4</a></li> 4644 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.8">7.3</a></li> 4645 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.3">5.4</a></li> 4646 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.7">7.3</a></li> 4638 4647 </ul> 4639 4648 </li> … … 4725 4734 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">8.3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li> 4726 4735 <li><em>RFC6151</em> <a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li> 4736 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">4.3.8</a>, <a href="#RFC6265"><b>11.2</b></a></li> 4727 4737 <li><em>RFC6266</em> <a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">B</a>, <a href="#rfc.xref.RFC6266.2">C</a></li> 4728 4738 <li><em>RFC6365</em> <a href="#rfc.xref.RFC6365.1">1.2</a>, <a href="#rfc.xref.RFC6365.2">3.1.1.2</a>, <a href="#RFC6365"><b>11.1</b></a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2070 r2071 480 480 </artwork></figure> 481 481 <t> 482 A sender &SHOULD; include a Content-Type header field in a message483 containing a payload body, defining the media type of the enclosed484 representation, unless the intended media typeis unknown to the sender.482 A sender that generates a message containing a payload body &SHOULD; 483 generate a Content-Type header field in that message unless the intended 484 media type of the enclosed representation is unknown to the sender. 485 485 If a Content-Type header field is not present, recipients &MAY; either 486 486 assume a media type of … … 1672 1672 <iref primary="true" item="TRACE method" x:for-anchor=""/> 1673 1673 <t> 1674 The TRACE method requests a remote, application-level loop-back 1675 of the request message. The final recipient of the request 1676 &SHOULD; reflect the message received back to the client as the message body 1677 of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the 1678 origin server or the first proxy to receive a <x:ref>Max-Forwards</x:ref> 1679 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 1680 A TRACE request &MUST-NOT; include a message body. 1674 The TRACE method requests a remote, application-level loop-back of the 1675 request message. The final recipient of the request &SHOULD; reflect the 1676 message received, excluding some fields described below, back to the client 1677 as the message body of a <x:ref>200 (OK)</x:ref> response with a 1678 <x:ref>Content-Type</x:ref> of "message/http" (&media-type-message-http;). 1679 The final recipient is either the origin server or the first server to 1680 receive a <x:ref>Max-Forwards</x:ref> value of zero (0) in the request 1681 (<xref target="header.max-forwards"/>). 1682 </t> 1683 <t> 1684 A client &MUST-NOT; send a message body in a TRACE request. 1685 </t> 1686 <t> 1687 A client &MUST-NOT; send header fields in a TRACE request containing 1688 sensitive data that might be disclosed by the response. For example, it 1689 would be foolish for a user agent to send stored user credentials 1690 <xref target="Part7"/> or cookies <xref target="RFC6265"/> in a TRACE 1691 request. The final recipient &SHOULD; exclude any request header fields 1692 from the response body that are likely to contain sensitive data. 1681 1693 </t> 1682 1694 <t> … … 1686 1698 is of particular interest, since it acts as a trace of the request chain. 1687 1699 Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to 1688 limit the length of the request chain, which is useful for testing a chain of 1689 proxies forwarding messages in an infinite loop. 1690 </t> 1691 <t> 1692 If the request is valid, the response &SHOULD; have a 1693 <x:ref>Content-Type</x:ref> of "message/http" (see &media-type-message-http;) 1694 and contain a message body that encloses a copy of the entire request message. 1700 limit the length of the request chain, which is useful for testing a chain 1701 of proxies forwarding messages in an infinite loop. 1702 </t> 1703 <t> 1695 1704 Responses to the TRACE method are not cacheable. 1696 1705 </t> … … 5511 5520 </reference> 5512 5521 5522 <reference anchor="RFC6265"> 5523 <front> 5524 <title>HTTP State Management Mechanism</title> 5525 <author initials="A." surname="Barth" fullname="Adam Barth"> 5526 <organization abbrev="U.C. Berkeley"> 5527 University of California, Berkeley 5528 </organization> 5529 <address><email>abarth@eecs.berkeley.edu</email></address> 5530 </author> 5531 <date year="2011" month="April" /> 5532 </front> 5533 <seriesInfo name="RFC" value="6265"/> 5534 </reference> 5535 5513 5536 <reference anchor="RFC6266"> 5514 5537 <front>
Note: See TracChangeset
for help on using the changeset viewer.