Changeset 2146 for draft-ietf-httpbis/latest

Timestamp:

21/01/13 06:20:05 (10 years ago)

Author:

fielding@…

Message:

Allow recipients to reject obsolete line folding; addresses #409

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (1 diff)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 16, 2013"; 
+       content: "Expires July 24, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -520 +520 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">January 12, 2013</td>
+               <td class="right">January 20, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: July 16, 2013</td>
+               <td class="left">Expires: July 24, 2013</td>
                <td class="right"></td>
             </tr>
@@ -551 +551 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 16, 2013.</p>
+      <p>This Internet-Draft will expire on July 24, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1265 +1265 @@
       <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
          space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
-         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the
-         message is intended for packaging within the message/http media type. Recipients <em class="bcp14">MUST</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets
-         (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
+         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. When an <a href="#header.fields" class="smpl">obs-fold</a> is received in a message, recipients <em class="bcp14">MUST</em> do one of: 
+      </p>
+      <ul>
+         <li>accept the message and replace any embedded <a href="#header.fields" class="smpl">obs-fold</a> whitespace with either a single <a href="#core.rules" class="smpl">SP</a> or a matching number of <a href="#core.rules" class="smpl">SP</a> octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream;
+         </li>
+         <li>if it is a request, reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response with a representation explaining that obsolete line folding is unacceptable; or,
+         </li>
+         <li>if it is a response, discard the message and generate a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response with a representation explaining that unacceptable line folding was received.
+         </li>
+      </ul>
+      <p> Recipients that choose not to implement <a href="#header.fields" class="smpl">obs-fold</a> processing (as described above) <em class="bcp14">MUST NOT</em> accept messages containing header fields with leading whitespace, as this can expose them to attacks that exploit this difference
+         in processing.
       </p>
       <p id="rfc.section.3.2.4.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -1305 +1305 @@
    Historically, HTTP header field values could be extended over multiple
    lines by preceding each extra line with at least one space or horizontal
-   tab (obs-fold). This specification deprecates such line
-   folding except within the message/http media type
+   tab (obs-fold). This specification deprecates such line folding except
+   within the message/http media type
    (<xref target="internet.media.type.message.http"/>).
    Senders &MUST-NOT; generate messages that include line folding
-   (i.e., that contain any field-value that matches the obs-fold rule) unless
-   the message is intended for packaging within the message/http media type.
-   Recipients &MUST; accept line folding and replace any embedded
-   obs-fold whitespace with either a single SP or a matching number of SP
-   octets (to avoid buffer copying) prior to interpreting the field value or
-   forwarding the message downstream.
+   (i.e., that contain any field-value that contains a match to the
+   <x:ref>obs-fold</x:ref> rule) unless the message is intended for packaging
+   within the message/http media type. When an <x:ref>obs-fold</x:ref> is
+   received in a message, recipients &MUST; do one of:
+   <list style="symbols">
+      <t>accept the message and replace any embedded <x:ref>obs-fold</x:ref>
+         whitespace with either a single <x:ref>SP</x:ref> or a matching
+         number of <x:ref>SP</x:ref> octets (to avoid buffer copying) prior to
+         interpreting the field value or forwarding the message
+         downstream;</t>
+
+      <t>if it is a request, reject the message by sending a
+         <x:ref>400 (Bad Request)</x:ref> response with a representation
+         explaining that obsolete line folding is unacceptable; or,</t>
+         
+      <t>if it is a response, discard the message and generate a
+         <x:ref>502 (Bad Gateway)</x:ref> response with a representation
+         explaining that unacceptable line folding was received.</t>
+   </list>
+   Recipients that choose not to implement <x:ref>obs-fold</x:ref> processing
+   (as described above) &MUST-NOT; accept messages containing header fields
+   with leading whitespace, as this can expose them to attacks that exploit
+   this difference in processing.
 </t>
 <t>