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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.