Changeset 2071 for draft-ietf-httpbis/latest/p2-semantics.xml

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

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (4 diffs)

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -480 +480 @@
 </artwork></figure>
 <t>
-   A sender &SHOULD; include a Content-Type header field in a message
-   containing a payload body, defining the media type of the enclosed
-   representation, unless the intended media type is unknown to the sender.
+   A sender that generates a message containing a payload body &SHOULD;
+   generate a Content-Type header field in that message unless the intended
+   media type of the enclosed representation is unknown to the sender.
    If a Content-Type header field is not present, recipients &MAY; either
    assume a media type of
@@ -1672 +1672 @@
   <iref primary="true" item="TRACE method" x:for-anchor=""/>
 <t>
-   The TRACE method requests a remote, application-level loop-back
-   of the request message. The final recipient of the request
-   &SHOULD; reflect the message received back to the client as the message body
-   of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the
-   origin server or the first proxy to receive a <x:ref>Max-Forwards</x:ref>
-   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
-   A TRACE request &MUST-NOT; include a message body.
+   The TRACE method requests a remote, application-level loop-back of the
+   request message. The final recipient of the request &SHOULD; reflect the
+   message received, excluding some fields described below, back to the client
+   as the message body of a <x:ref>200 (OK)</x:ref> response with a
+   <x:ref>Content-Type</x:ref> of "message/http" (&media-type-message-http;).
+   The final recipient is either the origin server or the first server to
+   receive a <x:ref>Max-Forwards</x:ref> value of zero (0) in the request
+   (<xref target="header.max-forwards"/>).
+</t>
+<t>
+   A client &MUST-NOT; send a message body in a TRACE request.
+</t>
+<t>
+   A client &MUST-NOT; send header fields in a TRACE request containing
+   sensitive data that might be disclosed by the response. For example, it
+   would be foolish for a user agent to send stored user credentials
+   <xref target="Part7"/> or cookies <xref target="RFC6265"/> in a TRACE
+   request. The final recipient &SHOULD; exclude any request header fields
+   from the response body that are likely to contain sensitive data.
 </t>
 <t>
@@ -1686 +1698 @@
    is of particular interest, since it acts as a trace of the request chain.
    Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
-   limit the length of the request chain, which is useful for testing a chain of
-   proxies forwarding messages in an infinite loop.
-</t>
-<t>
-   If the request is valid, the response &SHOULD; have a
-   <x:ref>Content-Type</x:ref> of "message/http" (see &media-type-message-http;)
-   and contain a message body that encloses a copy of the entire request message.
+   limit the length of the request chain, which is useful for testing a chain
+   of proxies forwarding messages in an infinite loop.
+</t>
+<t>
    Responses to the TRACE method are not cacheable.
 </t>
@@ -5511 +5520 @@
 </reference>
 
+<reference anchor="RFC6265">
+  <front>
+    <title>HTTP State Management Mechanism</title>
+    <author initials="A." surname="Barth" fullname="Adam Barth">
+      <organization abbrev="U.C. Berkeley">
+        University of California, Berkeley
+      </organization>
+      <address><email>abarth@eecs.berkeley.edu</email></address>
+    </author>
+    <date year="2011" month="April" />
+  </front>
+  <seriesInfo name="RFC" value="6265"/>
+</reference>
+
 <reference anchor="RFC6266">
   <front>