Changeset 2146


Ignore:
Timestamp:
Jan 20, 2013, 10:20:05 PM (7 years ago)
Author:
fielding@…
Message:

Allow recipients to reject obsolete line folding; addresses #409

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2116 r2146  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 16, 2013";
     451       content: "Expires July 24, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-20">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">January 12, 2013</td>
     522               <td class="right">January 20, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: July 16, 2013</td>
     525               <td class="left">Expires: July 24, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on July 16, 2013.</p>
     553      <p>This Internet-Draft will expire on July 24, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    12651265      <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
    12661266         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1267          (<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
    1268          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
    1269          (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
     1267         (<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:
     1268      </p>
     1269      <ul>
     1270         <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;
     1271         </li>
     1272         <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,
     1273         </li>
     1274         <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.
     1275         </li>
     1276      </ul>
     1277      <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
     1278         in processing.
    12701279      </p>
    12711280      <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

    r2116 r2146  
    13051305   Historically, HTTP header field values could be extended over multiple
    13061306   lines by preceding each extra line with at least one space or horizontal
    1307    tab (obs-fold). This specification deprecates such line
    1308    folding except within the message/http media type
     1307   tab (obs-fold). This specification deprecates such line folding except
     1308   within the message/http media type
    13091309   (<xref target="internet.media.type.message.http"/>).
    13101310   Senders &MUST-NOT; generate messages that include line folding
    1311    (i.e., that contain any field-value that matches the obs-fold rule) unless
    1312    the message is intended for packaging within the message/http media type.
    1313    Recipients &MUST; accept line folding and replace any embedded
    1314    obs-fold whitespace with either a single SP or a matching number of SP
    1315    octets (to avoid buffer copying) prior to interpreting the field value or
    1316    forwarding the message downstream.
     1311   (i.e., that contain any field-value that contains a match to the
     1312   <x:ref>obs-fold</x:ref> rule) unless the message is intended for packaging
     1313   within the message/http media type. When an <x:ref>obs-fold</x:ref> is
     1314   received in a message, recipients &MUST; do one of:
     1315   <list style="symbols">
     1316      <t>accept the message and replace any embedded <x:ref>obs-fold</x:ref>
     1317         whitespace with either a single <x:ref>SP</x:ref> or a matching
     1318         number of <x:ref>SP</x:ref> octets (to avoid buffer copying) prior to
     1319         interpreting the field value or forwarding the message
     1320         downstream;</t>
     1321
     1322      <t>if it is a request, reject the message by sending a
     1323         <x:ref>400 (Bad Request)</x:ref> response with a representation
     1324         explaining that obsolete line folding is unacceptable; or,</t>
     1325         
     1326      <t>if it is a response, discard the message and generate a
     1327         <x:ref>502 (Bad Gateway)</x:ref> response with a representation
     1328         explaining that unacceptable line folding was received.</t>
     1329   </list>
     1330   Recipients that choose not to implement <x:ref>obs-fold</x:ref> processing
     1331   (as described above) &MUST-NOT; accept messages containing header fields
     1332   with leading whitespace, as this can expose them to attacks that exploit
     1333   this difference in processing.
    13171334</t>
    13181335<t>
Note: See TracChangeset for help on using the changeset viewer.