Ignore:
Timestamp:
Dec 4, 2012, 4:58:55 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) Deal with first half of mnot p1 feedback; addresses #408

File:
1 edited

Legend:

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

    r2029 r2030  
    185185</t>
    186186<t>
    187    One consequence of HTTP flexibility is that the protocol cannot be
     187   One consequence of this flexibility is that the protocol cannot be
    188188   defined in terms of what occurs behind the interface. Instead, we
    189189   are limited to defining the syntax of communication, the intent
     
    298298   The terms client and server refer only to the roles that
    299299   these programs perform for a particular connection.  The same program
    300    might act as a client on some connections and a server on others.  We use
    301    the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request,
    302    such as a WWW browser, editor, or spider (web-traversing robot), and
    303    the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate
    304    authoritative responses to a request.  For general requirements, we use
    305    the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message
    306    and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the
    307    message.
     300   might act as a client on some connections and a server on others.
     301   We use the term "<x:dfn>user agent</x:dfn>" to refer to any of the various
     302   client programs that initiate a request, including (but not limited to)
     303   browsers, spiders (web-based robots), command-line tools, native
     304   applications, and mobile apps.  The term "<x:dfn>origin server</x:dfn>" is
     305   used to refer to the program that can originate authoritative responses to
     306   a request. For general requirements, we use the terms
     307   "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" to refer to any
     308   component that sends or receives, respectively, a given message.
    308309</t>
    309310<t>
     
    887888   invocation options, configuration files, or bookmark lists, even
    888889   though such usage might expose a user identifier or password.
    889    Senders &MUST-NOT; include a userinfo subcomponent (and its "@"
    890    delimiter) when transmitting an "http" URI in a message.  Recipients
    891    of HTTP messages that contain a URI reference &SHOULD; parse for the
    892    existence of userinfo and treat its presence as an error, likely
    893    indicating that the deprecated subcomponent is being used to obscure
     890   Senders &MUST; exclude the userinfo subcomponent (and its "@"
     891   delimiter) when an "http" URI is transmitted within a message as a
     892   request target or header field value.
     893   Recipients of an "http" URI reference &SHOULD; parse for userinfo and
     894   treat its presence as an error, since it is likely being used to obscure
    894895   the authority for the sake of phishing attacks.
    895896</t>
     
    10681069  <x:ref>request-line</x:ref>   = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref>
    10691070</artwork></figure>
    1070 <t>
    1071    A server &MUST; be able to parse any received message that begins
    1072    with a request-line and matches the ABNF rule for HTTP-message.
    1073 </t>
    10741071<iref primary="true" item="method"/>
    10751072<t anchor="method">
     
    11201117   Various ad-hoc limitations on request-line length are found in practice.
    11211118   It is &RECOMMENDED; that all HTTP senders and recipients support, at a
    1122    minimum, request-line lengths of up to 8000 octets.
     1119   minimum, request-line lengths of 8000 octets.
    11231120</t>
    11241121</section>
     
    11381135  <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref>
    11391136</artwork></figure>
    1140 <t>
    1141    A client &MUST; be able to parse any received message that begins
    1142    with a status-line and matches the ABNF rule for HTTP-message.
    1143 </t>
    11441137<t>
    11451138   The status-code element is a 3-digit integer code describing the
     
    11931186   timestamp for the message in which it appears.
    11941187</t>
     1188
     1189<section title="Field Extensibility" anchor="field.extensibility">
    11951190<t>
    11961191   HTTP header fields are fully extensible: there is no limit on the
    11971192   introduction of new field names, each presumably defining new semantics,
    1198    or on the number of header fields used in a given message.  Existing
     1193   nor on the number of header fields used in a given message.  Existing
    11991194   fields are defined in each part of this specification and in many other
    1200    specifications outside the standards process.
     1195   specifications outside the core standard.
    12011196   New header fields can be introduced without changing the protocol version
    12021197   if their defined semantics allow them to be safely ignored by recipients
     
    12121207   Unrecognized header fields &SHOULD; be ignored by other recipients.
    12131208</t>
     1209</section>
     1210
     1211<section title="Field Order" anchor="field.order">
    12141212<t>
    12151213   The order in which header fields with differing field names are
     
    12271225   sent in a message unless the entire field value for that
    12281226   header field is defined as a comma-separated list [i.e., #(values)].
     1227</t>
     1228<t>
    12291229   Multiple header fields with the same field name can be combined into
    12301230   one "field-name: field-value" pair, without changing the semantics of the
     
    12381238<x:note>
    12391239  <t>
    1240    &Note; The "Set-Cookie" header field as implemented in
    1241    practice can occur multiple times, but does not use the list syntax, and
    1242    thus cannot be combined into a single line (<xref target="RFC6265"/>). (See Appendix A.2.3 of <xref target="Kri2001"/>
    1243    for details.)
    1244 </t>
     1240   &Note; In practice, the "Set-Cookie" header field (<xref target="RFC6265"/>)
     1241   often appears multiple times in a response message and does not use the
     1242   list syntax, violating the above requirements on multiple header fields
     1243   with the same name. Since it cannot be combined into a single field-value,
     1244   recipients ought to handle "Set-Cookie" as a special case while processing
     1245   header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.)
     1246  </t>
    12451247</x:note>
     1248</section>
    12461249
    12471250<section title="Whitespace" anchor="whitespace">
     
    12531256<t anchor="rule.OWS">
    12541257   The OWS rule is used where zero or more linear whitespace octets might
    1255    appear. OWS &SHOULD; either not be produced or be produced as a single
     1258   appear. OWS &SHOULD; either not be generated or be generated as a single
    12561259   SP. Multiple OWS octets that occur within field-content &SHOULD; either
    12571260   be replaced with a single SP or transformed to all SP octets (each
     
    12611264<t anchor="rule.RWS">
    12621265   RWS is used when at least one linear whitespace octet is required to
    1263    separate field tokens. RWS &SHOULD; be produced as a single SP.
     1266   separate field tokens. RWS &SHOULD; be generated as a single SP.
    12641267   Multiple RWS octets that occur within field-content &SHOULD; either
    12651268   be replaced with a single SP or transformed to all SP octets before
     
    12681271<t anchor="rule.BWS">
    12691272   BWS is used where the grammar allows optional whitespace, for historical
    1270    reasons, but senders &SHOULD-NOT; produce it in messages;
     1273   reasons, but senders &SHOULD-NOT; generate it in messages;
    12711274   recipients &MUST; accept such bad optional whitespace and remove it before
    12721275   interpreting the field value or forwarding the message downstream.
     
    13111314   folding except within the message/http media type
    13121315   (<xref target="internet.media.type.message.http"/>).
    1313    HTTP senders &MUST-NOT; produce messages that include line folding
     1316   HTTP senders &MUST-NOT; generate messages that include line folding
    13141317   (i.e., that contain any field-value that matches the obs-fold rule) unless
    13151318   the message is intended for packaging within the message/http media type.
     
    13311334</section>
    13321335
    1333 <section title="Field Length" anchor="field.length">
    1334 <t>
    1335    HTTP does not place a pre-defined limit on the length of header fields,
    1336    either in isolation or as a set. A server &MUST; be prepared to receive
    1337    request header fields of unbounded length and respond with a <x:ref>4xx
    1338    (Client Error)</x:ref> status code if the received header field(s) would be
    1339    longer than the server wishes to handle.
    1340 </t>
    1341 <t>
    1342    A client that receives response header fields that are longer than it wishes
    1343    to handle can only treat it as a server error.
    1344 </t>
    1345 <t>
    1346    Various ad-hoc limitations on header field length are found in practice. It
    1347    is &RECOMMENDED; that all HTTP senders and recipients support messages whose
    1348    combined header fields have 4000 or more octets.
     1336<section title="Field Limits" anchor="field.limits">
     1337<t>
     1338   HTTP does not place a pre-defined limit on the length of each header field
     1339   or on the length of the header block as a whole.  Various ad-hoc
     1340   limitations on individual header field length are found in practice,
     1341   often depending on the specific field semantics.
     1342</t>
     1343<t>
     1344   A server &MUST; be prepared to receive request header fields of unbounded
     1345   length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref>
     1346   status code if the received header field(s) are larger than the server
     1347   wishes to process.
     1348</t>
     1349<t>
     1350   A client &MUST; be prepared to receive response header fields of unbounded
     1351   length. A client &MAY; discard or truncate received header fields that are
     1352   larger than the client wishes to process if the field semantics are such
     1353   that the dropped value(s) can be safely ignored without changing the
     1354   response semantics.
    13491355</t>
    13501356</section>
     
    13981404</artwork></figure>
    13991405<t>
    1400    Recipients that process the value of the quoted-string &MUST; handle a
     1406   Recipients that process the value of a quoted-string &MUST; handle a
    14011407   quoted-pair as if it were replaced by the octet following the backslash.
    14021408</t>
    14031409<t>
    1404    Senders &SHOULD-NOT; escape octets in quoted-strings that do not require
    1405    escaping (i.e., other than DQUOTE and the backslash octet).
     1410   Senders &SHOULD-NOT; generate a quoted-pair in a quoted-string except where
     1411   necessary to quote DQUOTE and backslash octets occurring within that string.
    14061412</t>
    14071413<t anchor="rule.comment">
     
    18911897   transfer it as a series of chunks, each with its own size indicator,
    18921898   followed by an &OPTIONAL; trailer containing header fields. This
    1893    allows dynamically produced content to be transferred along with the
     1899   allows dynamically generated content to be transferred along with the
    18941900   information necessary for the recipient to verify that it has
    18951901   received the full message.
     
    47024708   with a "Connection: keep-alive" request header field. However, some
    47034709   experimental implementations of HTTP/1.0 persistent connections are faulty;
    4704    for example, if a HTTP/1.0 proxy server doesn't understand
     4710   for example, if an HTTP/1.0 proxy server doesn't understand
    47054711   <x:ref>Connection</x:ref>, it will erroneously forward that header field
    47064712   to the next inbound server, which would result in a hung connection.
Note: See TracChangeset for help on using the changeset viewer.