Changeset 2260 for draft-ietf-httpbis


Ignore:
Timestamp:
19/05/13 22:21:45 (7 years ago)
Author:
fielding@…
Message:

(editorial) Replace the confusing list of bullets for obs-fold handling with separate paragraphs for each type of recipient; Move the requirements for invalid fold space before the first header field into the section that defines the corresponding ABNF; addresses #444

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

Legend:

Unmodified
Added
Removed

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

    r2259 r2260  
    11321132         sake of network efficiency, security checks, or payload transformations.
    11331133      </p>
     1134      <p id="rfc.section.3.p.6">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line
     1135         and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore
     1136         the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
     1137         or the header block is terminated).
     1138      </p>
     1139      <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing
     1140         the line after it as a new request, either of which might result in a security vulnerability if other implementations within
     1141         the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be
     1142         ignored by some clients or cause others to cease parsing.
     1143      </p>
    11341144      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="start.line" href="#start.line">Start Line</a></h2>
    11351145      <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
    … …  
    11421152      </p>
    11431153      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#http.message" class="smpl">start-line</a>     = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a>
    1144 </pre><p id="rfc.section.3.1.p.4">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
    1145          attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might
    1146          result in a security vulnerability if other implementations within the request chain interpret the same message differently.
    1147          Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing.
    1148       </p>
    1149       <p id="rfc.section.3.1.p.5">A recipient that receives whitespace between the start-line and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore
    1150          the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
    1151          or the header block is terminated).
    1152       </p>
    1153       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="request.line" href="#request.line">Request Line</a></h3>
     1154</pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="request.line" href="#request.line">Request Line</a></h3>
    11541155      <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP),
    11551156         the protocol version, and ending with CRLF.
    … …  
    12751276      <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    12761277         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1277          (<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:
    1278       </p>
    1279       <ul>
    1280          <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;
    1281          </li>
    1282          <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,
    1283          </li>
    1284          <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.
    1285          </li>
    1286       </ul>
    1287       <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
    1288          in processing.
    1289       </p>
    1290       <p id="rfc.section.3.2.4.p.5">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.
     1278         (<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.
     1279      </p>
     1280      <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
     1281      </p>
     1282      <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream.
     1283      </p>
     1284      <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value.
     1285      </p>
     1286      <p id="rfc.section.3.2.4.p.8">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.
    12911287      </p>
    12921288      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>

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

    r2259 r2260  
    10171017   checks, or payload transformations.
    10181018</t>
    1019 
    1020 <section title="Start Line" anchor="start.line">
    1021   <x:anchor-alias value="Start-Line"/>
    1022 <t>
    1023    An HTTP message can either be a request from client to server or a
    1024    response from server to client.  Syntactically, the two types of message
    1025    differ only in the start-line, which is either a request-line (for requests)
    1026    or a status-line (for responses), and in the algorithm for determining
    1027    the length of the message body (<xref target="message.body"/>).
    1028 </t>
    1029 <t>
    1030    In theory, a client could receive requests and a server could receive
    1031    responses, distinguishing them by their different start-line formats,
    1032    but in practice servers are implemented to only expect a request
    1033    (a response is interpreted as an unknown or invalid request method)
    1034    and clients are implemented to only expect a response.
    1035 </t>
    1036 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/>
    1037   <x:ref>start-line</x:ref>     = <x:ref>request-line</x:ref> / <x:ref>status-line</x:ref>
    1038 </artwork></figure>
    10391019<t>
    10401020   A sender &MUST-NOT; send whitespace between the start-line and
    1041    the first header field. The presence of such whitespace in a request
     1021   the first header field.
     1022   A recipient that receives whitespace between the start-line and
     1023   the first header field &MUST; either reject the message as invalid or
     1024   consume each whitespace-preceded line without further processing of it
     1025   (i.e., ignore the entire line, along with any subsequent lines preceded
     1026   by whitespace, until a properly formed header field is received or the
     1027   header block is terminated).
     1028</t>
     1029<t>
     1030   The presence of such whitespace in a request
    10421031   might be an attempt to trick a server into ignoring that field or
    10431032   processing the line after it as a new request, either of which might
    … …  
    10471036   ignored by some clients or cause others to cease parsing.
    10481037</t>
    1049 <t>
    1050    A recipient that receives whitespace between the start-line and
    1051    the first header field &MUST; either reject the message as invalid or
    1052    consume each whitespace-preceded line without further processing of it
    1053    (i.e., ignore the entire line, along with any subsequent lines preceded
    1054    by whitespace, until a properly formed header field is received or the
    1055    header block is terminated).
    1056 </t>
     1038
     1039<section title="Start Line" anchor="start.line">
     1040  <x:anchor-alias value="Start-Line"/>
     1041<t>
     1042   An HTTP message can either be a request from client to server or a
     1043   response from server to client.  Syntactically, the two types of message
     1044   differ only in the start-line, which is either a request-line (for requests)
     1045   or a status-line (for responses), and in the algorithm for determining
     1046   the length of the message body (<xref target="message.body"/>).
     1047</t>
     1048<t>
     1049   In theory, a client could receive requests and a server could receive
     1050   responses, distinguishing them by their different start-line formats,
     1051   but in practice servers are implemented to only expect a request
     1052   (a response is interpreted as an unknown or invalid request method)
     1053   and clients are implemented to only expect a response.
     1054</t>
     1055<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/>
     1056  <x:ref>start-line</x:ref>     = <x:ref>request-line</x:ref> / <x:ref>status-line</x:ref>
     1057</artwork></figure>
    10571058
    10581059<section title="Request Line" anchor="request.line">
    … …  
    13181319   (i.e., that contain any field-value that contains a match to the
    13191320   <x:ref>obs-fold</x:ref> rule) unless the message is intended for packaging
    1320    within the message/http media type. When an <x:ref>obs-fold</x:ref> is
    1321    received in a message, recipients &MUST; do one of:
    1322    <list style="symbols">
    1323       <t>accept the message and replace any embedded <x:ref>obs-fold</x:ref>
    1324          whitespace with either a single <x:ref>SP</x:ref> or a matching
    1325          number of <x:ref>SP</x:ref> octets (to avoid buffer copying) prior to
    1326          interpreting the field value or forwarding the message
    1327          downstream;</t>
    1328 
    1329       <t>if it is a request, reject the message by sending a
    1330          <x:ref>400 (Bad Request)</x:ref> response with a representation
    1331          explaining that obsolete line folding is unacceptable; or,</t>
    1332          
    1333       <t>if it is a response, discard the message and generate a
    1334          <x:ref>502 (Bad Gateway)</x:ref> response with a representation
    1335          explaining that unacceptable line folding was received.</t>
    1336    </list>
    1337    Recipients that choose not to implement <x:ref>obs-fold</x:ref> processing
    1338    (as described above) &MUST-NOT; accept messages containing header fields
    1339    with leading whitespace, as this can expose them to attacks that exploit
    1340    this difference in processing.
     1321   within the message/http media type.
     1322</t>
     1323<t>
     1324   A server that receives an <x:ref>obs-fold</x:ref> in a request message that
     1325   is not within a message/http container &MUST; either reject the message by
     1326   sending a <x:ref>400 (Bad Request)</x:ref>, preferably with a
     1327   representation explaining that obsolete line folding is unacceptable, or
     1328   replace each received <x:ref>obs-fold</x:ref> with one or more
     1329   <x:ref>SP</x:ref> octets prior to interpreting the field value or
     1330   forwarding the message downstream.
     1331</t>
     1332<t>
     1333   A proxy or gateway that receives an <x:ref>obs-fold</x:ref> in a response
     1334   message that is not within a message/http container &MUST; either discard
     1335   the message and replace it with a <x:ref>502 (Bad Gateway)</x:ref>
     1336   response, preferably with a representation explaining that unacceptable
     1337   line folding was received, or replace each received <x:ref>obs-fold</x:ref>
     1338   with one or more <x:ref>SP</x:ref> octets prior to interpreting the field
     1339   value or forwarding the message downstream.
     1340</t>
     1341<t>
     1342   A user agent that receives an <x:ref>obs-fold</x:ref> in a response message
     1343   that is not within a message/http container &MUST; replace each received
     1344   <x:ref>obs-fold</x:ref> with one or more <x:ref>SP</x:ref> octets prior to
     1345   interpreting the field value.
    13411346</t>
    13421347<t>
Note: See TracChangeset for help on using the changeset viewer.