Changeset 2071 for draft-ietf-httpbis


Ignore:
Timestamp:
31/12/12 06:09:31 (9 years ago)
Author:
fielding@…
Message:

add Darwinian requirements to TRACE; fix several more cases of include being used instead of send

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r2070 r2071  
    13381338      </p>
    13391339      <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&nbsp;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&nbsp;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.
    13411342      </p>
    13421343      <div id="rfc.iref.t.4"></div>
    … …  
    19351936  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    19361937</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>).
    19391939      </p>
    19401940      <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
    … …  
    20432043      <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.
    20442044      </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> include 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.
     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.
    20462046      </p>
    20472047      <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  
    14661466   mode instead of having a message body (&CONNECT;).
    14671467   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.
    14691469   All other responses do include a message body, although the body
    1470    &MAY; be of zero length.
     1470   might be of zero length.
    14711471</t>
    14721472
    … …  
    27182718</t>
    27192719<t>
    2720    A sender &MUST-NOT; include field-names in the Connection header
    2721    field-value for fields that are defined as expressing constraints
    2722    for all recipients in the request or response chain, such as the
    2723    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;).
    27242724</t>
    27252725<t>
    … …  
    29662966   initiate a lingering close (see below) of the connection after it sends the
    29672967   final response to the request that contained <x:ref>close</x:ref>.
    2968    The server &SHOULD; include a <x:ref>close</x:ref> connection option
     2968   The server &SHOULD; send a <x:ref>close</x:ref> connection option
    29692969   in its final response on that connection. The server &MUST-NOT; process
    29702970   any further requests received on that connection.
    … …  
    39983998  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    39993999  <x:source href="p6-cache.xml" basename="p6-cache">
     4000    <x:defines>Cache-Control</x:defines>
    40004001    <x:defines>Expires</x:defines>
    40014002  </x:source>

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

    r2070 r2071  
    960960      </p>
    961961      <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 unknown 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.
     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.
    964964      </p>
    965965      <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
    … …  
    15911591      <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
    15921592      <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&nbsp;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&nbsp;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
    15971602         messages in an infinite loop.
    15981603      </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>
    16011605      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>
    16021606      <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
    … …  
    20062010               <tr>
    20072011                  <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>
    20092013               </tr>
    20102014               <tr>
    20112015                  <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>
    20132017               </tr>
    20142018            </tbody>
    … …  
    21332137      </ul>
    21342138      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<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 the
     2139      <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
    21362140         protocol.
    21372141      </p>
    … …  
    22342238                  <td class="left">401</td>
    22352239                  <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>
    22372241               </tr>
    22382242               <tr>
    … …  
    22642268                  <td class="left">407</td>
    22652269                  <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>
    22672271               </tr>
    22682272               <tr>
    … …  
    30303034               <tr>
    30313035                  <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>
    30333037               </tr>
    30343038               <tr>
    30353039                  <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>
    30373041               </tr>
    30383042            </tbody>
    … …  
    39283932      <h2 id="rfc.references.2"><a href="#rfc.section.11.2" id="rfc.section.11.2">11.2</a> Informative References
    39293933      </h2>
    3930       <table>                                         
     3934      <table>                                           
    39313935         <tr>
    39323936            <td class="reference"><b id="BCP13">[BCP13]</b></td>
    … …  
    40224026            <td class="reference"><b id="RFC6151">[RFC6151]</b></td>
    40234027            <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&nbsp;6151, March&nbsp;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="&#xA;        University of California, Berkeley&#xA;      ">Barth, A.</a>, “<a href="http://tools.ietf.org/html/rfc6265">HTTP State Management Mechanism</a>”, RFC&nbsp;6265, April&nbsp;2011.
    40244033            </td>
    40254034         </tr>
    … …  
    45864595                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">5.1</a></li>
    45874596                        <li><em>Section 5.5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li>
     4597                        <li><em>Section 5.7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.44">C</a></li>
    45894598                        <li><em>Section 5.7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">6.3.4</a></li>
    45904599                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.35">8.3.1</a></li>
    45914600                        <li><em>Section 6.7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">4.3.8</a></li>
     4601                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">4.3.8</a></li>
    45934602                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">10</a></li>
    45944603                        <li><em>Appendix B</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">8.3.1</a></li>
    … …  
    46284637                     </ul>
    46294638                  </li>
    4630                   <li><em>Part7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part7.3">6.1</a></li>
    4632                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.4">6.1</a></li>
    4633                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.5">6.1</a></li>
    4634                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.1">5.4</a></li>
    4635                         <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.7">7.3</a></li>
    4636                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.2">5.4</a></li>
    4637                         <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.6">7.3</a></li>
     4639                  <li><em>Part7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part7.4">6.1</a></li>
     4641                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.5">6.1</a></li>
     4642                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.6">6.1</a></li>
     4643                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.2">5.4</a></li>
     4644                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.8">7.3</a></li>
     4645                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.3">5.4</a></li>
     4646                        <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part7.7">7.3</a></li>
    46384647                     </ul>
    46394648                  </li>
    … …  
    47254734                  <li><em>RFC5987</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5987.1">8.3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li>
    47264735                  <li><em>RFC6151</em>&nbsp;&nbsp;<a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">C</a></li>
     4736                  <li><em>RFC6265</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC6265.1">4.3.8</a>, <a href="#RFC6265"><b>11.2</b></a></li>
    47274737                  <li><em>RFC6266</em>&nbsp;&nbsp;<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>
    47284738                  <li><em>RFC6365</em>&nbsp;&nbsp;<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  
    480480</artwork></figure>
    481481<t>
    482    A sender &SHOULD; include a Content-Type header field in a message
    483    containing a payload body, defining the media type of the enclosed
    484    representation, unless the intended media type is 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.
    485485   If a Content-Type header field is not present, recipients &MAY; either
    486486   assume a media type of
    … …  
    16721672  <iref primary="true" item="TRACE method" x:for-anchor=""/>
    16731673<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.
    16811693</t>
    16821694<t>
    … …  
    16861698   is of particular interest, since it acts as a trace of the request chain.
    16871699   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>
    16951704   Responses to the TRACE method are not cacheable.
    16961705</t>
    … …  
    55115520</reference>
    55125521
     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
    55135536<reference anchor="RFC6266">
    55145537  <front>
Note: See TracChangeset for help on using the changeset viewer.