Ignore:
Timestamp:
15/09/13 02:23:08 (7 years ago)
Author:
fielding@…
Message:

uniform terminology for private cache (not non-shared), user agent, and avoid plural subjects in requirements; clarify that recipients don't have to parse all received URIs; addresses #234

File:
1 edited

Legend:

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

    r2401 r2402  
    916916      <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    917917         depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple
    918          servers. Hence, servers <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
     918         servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
    919919         to that agent. Some non-standard HTTP extensions (e.g., <a href="#RFC4559" id="rfc.xref.RFC4559.1"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>) have been known to violate this requirement, resulting in security and interoperability problems.
    920920      </p>
     
    11011101      <p id="rfc.section.2.7.1.p.9">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal
    11021102         configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists,
    1103          even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a
    1104          request target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake
     1103         even though such usage might expose a user identifier or password. A sender <em class="bcp14">MUST NOT</em> generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a
     1104         request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient
     1105         ought to parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake
    11051106         of phishing attacks.
    11061107      </p>
     
    11551156         is read or the connection is closed.
    11561157      </p>
    1157       <p id="rfc.section.3.p.4">Recipients <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities
     1158      <p id="rfc.section.3.p.4">A recipient <em class="bcp14">MUST</em> parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII <a href="#USASCII" id="rfc.xref.USASCII.2"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities
    11581159         due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet
    11591160         LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from
     
    12021203         whitespace found in hypertext references, resulting in those disallowed characters being sent in a request-target.
    12031204      </p>
    1204       <p id="rfc.section.3.1.1.p.8">Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
     1205      <p id="rfc.section.3.1.1.p.8">Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. A recipient <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    12051206         crafted to bypass security filters along the request chain.
    12061207      </p>
     
    13131314      <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
    13141315         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    1315          (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;8.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.
     1316         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;8.3.1</a>). A sender <em class="bcp14">MUST NOT</em> generate a message that includes line folding (i.e., that has 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.
    13161317      </p>
    13171318      <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.
     
    13211322      <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.
    13221323      </p>
    1323       <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.
     1324      <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. A recipient <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
    13241325      </p>
    13251326      <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>
     
    13611362</pre><p id="rfc.section.3.2.6.p.7">Recipients that process the value of a quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash.
    13621363      </p>
    1363       <p id="rfc.section.3.2.6.p.8">Senders <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that
     1364      <p id="rfc.section.3.2.6.p.8">A sender <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that
    13641365         string.
    13651366      </p>
     
    13751376      </div>
    13761377      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a>   = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> )
    1377 </pre><p id="rfc.section.3.2.6.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
     1378</pre><p id="rfc.section.3.2.6.p.13">A sender <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and
    13781379         ")").
    13791380      </p>
     
    14031404         applied for transport efficiency or security from those that are characteristics of the selected resource.
    14041405      </p>
    1405       <p id="rfc.section.3.3.1.p.4">All HTTP/1.1 recipients <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer
     1406      <p id="rfc.section.3.3.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse the chunked transfer coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>) because it plays a crucial role in framing messages when the payload body size is not known in advance. A sender <em class="bcp14">MUST NOT</em> apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed). If any transfer
    14061407         coding other than chunked is applied to a request payload body, the sender <em class="bcp14">MUST</em> apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding other than
    14071408         chunked is applied to a response payload body, the sender <em class="bcp14">MUST</em> either apply chunked as the final transfer coding or terminate the message by closing the connection.
     
    14571458      </p>
    14581459      <p id="rfc.section.3.3.2.p.11">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of
    1459          a payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;9.3</a>).
     1460         a payload, a recipient <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Buffer Overflows">Section&nbsp;9.3</a>).
    14601461      </p>
    14611462      <p id="rfc.section.3.3.2.p.12">If a message is received that has multiple Content-Length header fields with field-values consisting of the same decimal value,
     
    15181519      </ol>
    15191520      <p id="rfc.section.3.3.3.p.3">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
    1520          by network failure, a server <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
    1521          with HTTP/1.0.
     1521         by network failure, a server <em class="bcp14">SHOULD</em> generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards
     1522         compatibility with HTTP/1.0.
    15221523      </p>
    15231524      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a <a href="#header.content-length" class="smpl">Content-Length</a> by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
     
    15571558      <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line.
    15581559      </p>
    1559       <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
     1560      <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR.
    15601561      </p>
    15611562      <p id="rfc.section.3.5.p.4">Although the request-line and status-line grammar rules require that each of the component elements be separated by a single
     
    16121613                 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding
    16131614  <a href="#chunked.encoding" class="smpl">qdtext-nf</a>      = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a>
    1614 </pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chunked transfer coding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged.
     1615</pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chunked transfer coding are deprecated. A sender <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged.
    16151616      </p>
    16161617      <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding
     
    16611662  Remove "chunked" from Transfer-Encoding
    16621663  Remove Trailer from existing header fields
    1663 </pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
     1664</pre><p id="rfc.section.4.1.2.p.3">A recipient <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.
    16641665      </p>
    16651666      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
     
    16671668      <div id="rfc.iref.c.10"></div>
    16681669      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="compress.coding" href="#compress.coding">Compress Coding</a></h3>
    1669       <p id="rfc.section.4.2.1.p.1">The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding <a href="#Welch" id="rfc.xref.Welch.1"><cite title="A Technique for High Performance Data Compression">[Welch]</cite></a> that is commonly produced by the UNIX file compression program "compress". Recipients <em class="bcp14">SHOULD</em> consider "x-compress" to be equivalent to "compress".
     1670      <p id="rfc.section.4.2.1.p.1">The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding <a href="#Welch" id="rfc.xref.Welch.1"><cite title="A Technique for High Performance Data Compression">[Welch]</cite></a> that is commonly produced by the UNIX file compression program "compress". A recipient <em class="bcp14">SHOULD</em> consider "x-compress" to be equivalent to "compress".
    16701671      </p>
    16711672      <div id="rfc.iref.d.2"></div>
     
    16791680      <div id="rfc.iref.g.76"></div>
    16801681      <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3>
    1681       <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. Recipients <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip".
     1682      <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip".
    16821683      </p>
    16831684      <div id="rfc.iref.t.5"></div>
     
    16871688      </p>
    16881689      <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as
    1689          described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
     1690         described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
    16901691      </p>
    16911692      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span>  <a href="#header.te" class="smpl">TE</a>        = #<a href="#header.te" class="smpl">t-codings</a>
     
    17941795      <p id="rfc.section.5.3.p.12">An example absolute-form of request-line would be:</p>
    17951796      <div id="rfc.figure.u.41"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1796 </pre><p id="rfc.section.5.3.p.14">To allow for transition to the absolute-form for all requests in some future version of HTTP, HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
     1797</pre><p id="rfc.section.5.3.p.14">To allow for transition to the absolute-form for all requests in some future version of HTTP, a server <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies.
    17971798      </p>
    17981799      <div id="authority-form">
     
    19481949</pre><p id="rfc.section.5.7.1.p.13">could be collapsed to</p>
    19491950      <div id="rfc.figure.u.55"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    1950 </pre><p id="rfc.section.5.7.1.p.15">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
    1951          by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
     1951</pre><p id="rfc.section.5.7.1.p.15">A sender <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
     1952         by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
    19521953      </p>
    19531954      <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformations" href="#message.transformations">Transformations</a></h3>
     
    20952096      </p>
    20962097      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h2>
    2097       <p id="rfc.section.6.4.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server.
     2098      <p id="rfc.section.6.4.p.1">A client <em class="bcp14">SHOULD</em> limit the number of simultaneous open connections that it maintains to a given server.
    20982099      </p>
    20992100      <p id="rfc.section.6.4.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many
     
    21192120         while it was idle, but from the client's point of view, a request is in progress.
    21202121      </p>
    2121       <p id="rfc.section.6.5.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads,
    2122          rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network
    2123          congestion.
    2124       </p>
    2125       <p id="rfc.section.6.5.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error response while it is transmitting the request. If the client sees an error response,
    2126          it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
     2122      <p id="rfc.section.6.5.p.4">A server <em class="bcp14">SHOULD</em> sustain persistent connections, when possible, and allow the underlying transport's flow control mechanisms to resolve temporary
     2123         overloads, rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate
     2124         network congestion.
     2125      </p>
     2126      <p id="rfc.section.6.5.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error response while it is transmitting the request. If the client sees a response that
     2127         indicates the server does not wish to receive the message body and is closing the connection, the client <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close its side of the connection.
    21272128      </p>
    21282129      <div id="rfc.iref.c.13"></div>
     
    22212222</pre><div id="rfc.figure.u.63"></div>
    22222223      <p>and for n &gt;= 1 and m &gt; 1:</p><pre class="text">  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
    2223 </pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">MUST</em> parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values,
    2224          but not so much that they could be used as a denial of service mechanism. In other words, recipients <em class="bcp14">MUST</em> expand the list construct as follows:
     2224</pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, a recipient <em class="bcp14">MUST</em> parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values,
     2225         but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> expand the list construct as follows:
    22252226      </p>
    22262227      <div id="rfc.figure.u.64"></div><pre class="text">  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
Note: See TracChangeset for help on using the changeset viewer.