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

Location:
draft-ietf-httpbis/latest
Files:
12 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 ] ) ]
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2401 r2402  
    550550   can be understood in isolation.  Many implementations depend on HTTP's
    551551   stateless design in order to reuse proxied connections or dynamically
    552    load-balance requests across multiple servers.  Hence, servers &MUST-NOT;
     552   load-balance requests across multiple servers.  Hence, a server &MUST-NOT;
    553553   assume that two requests on the same connection are from the same user
    554554   agent unless the connection is secured and specific to that agent.
     
    935935   invocation options, configuration files, or bookmark lists, even
    936936   though such usage might expose a user identifier or password.
    937    Senders &MUST-NOT; generate the userinfo subcomponent (and its "@"
     937   A sender &MUST-NOT; generate the userinfo subcomponent (and its "@"
    938938   delimiter) when an "http" URI reference is generated within a message as a
    939939   request target or header field value.
    940    Recipients of an "http" URI reference &SHOULD; parse for userinfo and
    941    treat its presence as an error, since it is likely being used to obscure
    942    the authority for the sake of phishing attacks.
     940   Before making use of an "http" URI reference received from an untrusted
     941   source, a recipient ought to parse for userinfo and treat its presence as
     942   an error; it is likely being used to obscure the authority for the sake of
     943   phishing attacks.
    943944</t>
    944945</section>
     
    10471048</t>
    10481049<t>
    1049    Recipients &MUST; parse an HTTP message as a sequence of octets in an
     1050   A recipient &MUST; parse an HTTP message as a sequence of octets in an
    10501051   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
    10511052   Parsing an HTTP message as a stream of Unicode characters, without regard
     
    11441145   Recipients of an invalid request-line &SHOULD; respond with either a
    11451146   <x:ref>400 (Bad Request)</x:ref> error or a <x:ref>301 (Moved Permanently)</x:ref>
    1146    redirect with the request-target properly encoded.  Recipients &SHOULD-NOT;
     1147   redirect with the request-target properly encoded.  A recipient &SHOULD-NOT;
    11471148   attempt to autocorrect and then process the request without a redirect,
    11481149   since the invalid request-line might be deliberately crafted to bypass
     
    13701371   within the message/http media type
    13711372   (<xref target="internet.media.type.message.http"/>).
    1372    Senders &MUST-NOT; generate messages that include line folding
    1373    (i.e., that contain any field-value that contains a match to the
     1373   A sender &MUST-NOT; generate a message that includes line folding
     1374   (i.e., that has any field-value that contains a match to the
    13741375   <x:ref>obs-fold</x:ref> rule) unless the message is intended for packaging
    13751376   within the message/http media type.
     
    14061407   US-ASCII charset <xref target="USASCII"/>. Newly defined
    14071408   header fields &SHOULD; limit their field values to US-ASCII octets.
    1408    Recipients &SHOULD; treat other octets in field content (obs-text) as
     1409   A recipient &SHOULD; treat other octets in field content (obs-text) as
    14091410   opaque data.
    14101411</t>
     
    14851486</t>
    14861487<t>
    1487    Senders &SHOULD-NOT; generate a quoted-pair in a quoted-string except where
     1488   A sender &SHOULD-NOT; generate a quoted-pair in a quoted-string except where
    14881489   necessary to quote DQUOTE and backslash octets occurring within that string.
    14891490</t>
     
    15081509</artwork></figure>
    15091510<t>
    1510    Senders &SHOULD-NOT; escape octets in comments that do not require escaping
     1511   A sender &SHOULD-NOT; escape octets in comments that do not require escaping
    15111512   (i.e., other than the backslash octet "\" and the parentheses "(" and ")").
    15121513</t>
     
    15771578</t>
    15781579<t>
    1579    All HTTP/1.1 recipients &MUST; be able to parse the chunked transfer coding
     1580   A recipient &MUST; be able to parse the chunked transfer coding
    15801581   (<xref target="chunked.encoding"/>) because it plays a crucial role in
    15811582   framing messages when the payload body size is not known in advance.
     
    17081709<t>
    17091710   Any Content-Length field value greater than or equal to zero is valid.
    1710    Since there is no predefined limit to the length of a payload,
    1711    recipients &SHOULD; anticipate potentially large decimal numerals and
     1711   Since there is no predefined limit to the length of a payload, a
     1712   recipient &SHOULD; anticipate potentially large decimal numerals and
    17121713   prevent parsing errors due to integer conversion overflows
    17131714   (<xref target="attack.protocol.element.size.overflows"/>).
     
    18211822   Since there is no way to distinguish a successfully completed,
    18221823   close-delimited message from a partially-received message interrupted
    1823    by network failure, a server &SHOULD; use encoding or
     1824   by network failure, a server &SHOULD; generate encoding or
    18241825   length-delimited messages whenever possible.  The close-delimiting
    18251826   feature exists primarily for backwards compatibility with HTTP/1.0.
     
    19111912<t>
    19121913   Although the line terminator for the start-line and header
    1913    fields is the sequence CRLF, recipients &MAY; recognize a
     1914   fields is the sequence CRLF, a recipient &MAY; recognize a
    19141915   single LF as a line terminator and ignore any preceding CR.
    19151916</t>
     
    20142015<t>
    20152016   Chunk extensions within the chunked transfer coding are deprecated.
    2016    Senders &SHOULD-NOT; send chunk-ext.
     2017   A sender &SHOULD-NOT; send chunk-ext.
    20172018   Definition of new chunk extensions is discouraged.
    20182019</t>
     
    20972098</artwork></figure>
    20982099<t>
    2099    All recipients &MUST; be able to parse and decode the
     2100   A recipient &MUST; be able to parse and decode the
    21002101   chunked transfer coding and &MUST; ignore chunk-ext extensions
    21012102   they do not understand.
     
    21162117   <xref target="Welch"/> that is commonly produced by the UNIX file
    21172118   compression program "compress".
    2118    Recipients &SHOULD; consider "x-compress" to be equivalent to "compress".
     2119   A recipient &SHOULD; consider "x-compress" to be equivalent to "compress".
    21192120</t>
    21202121</section>
     
    21412142   The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly
    21422143   produced by the gzip file compression program <xref target="RFC1952"/>.
    2143    Recipients &SHOULD; consider "x-gzip" to be equivalent to "gzip".
     2144   A recipient &SHOULD; consider "x-gzip" to be equivalent to "gzip".
    21442145</t>
    21452146</section>
     
    21632164   names, each allowing for optional parameters (as described in
    21642165   <xref target="transfer.codings"/>), and/or the keyword "trailers".
    2165    Clients &MUST-NOT; send the chunked transfer coding name in TE;
     2166   A client &MUST-NOT; send the chunked transfer coding name in TE;
    21662167   chunked is always acceptable for HTTP/1.1 recipients.
    21672168</t>
     
    23752376<t>
    23762377   To allow for transition to the absolute-form for all requests in some
    2377    future version of HTTP, HTTP/1.1 servers &MUST; accept the absolute-form
     2378   future version of HTTP, a server &MUST; accept the absolute-form
    23782379   in requests, even though HTTP/1.1 clients will only send them in requests
    23792380   to proxies.
     
    27222723</artwork></figure>
    27232724<t>
    2724    Senders &SHOULD-NOT; combine multiple entries unless they are all
     2725   A sender &SHOULD-NOT; combine multiple entries unless they are all
    27252726   under the same organizational control and the hosts have already been
    2726    replaced by pseudonyms. Senders &MUST-NOT; combine entries that
     2727   replaced by pseudonyms. A sender &MUST-NOT; combine entries that
    27272728   have different received-protocol values.
    27282729</t>
     
    30463047<section title="Concurrency" anchor="persistent.concurrency">
    30473048<t>
    3048    Clients &SHOULD; limit the number of simultaneous
    3049    connections that they maintain to a given server.
     3049   A client &SHOULD; limit the number of simultaneous open
     3050   connections that it maintains to a given server.
    30503051</t>
    30513052<t>
     
    30953096</t>
    30963097<t>
    3097    Servers &SHOULD; maintain persistent connections and allow the underlying
     3098   A server &SHOULD; sustain persistent connections, when possible, and allow
     3099   the underlying
    30983100   transport's flow control mechanisms to resolve temporary overloads, rather
    30993101   than terminate connections with the expectation that clients will retry.
     
    31033105   A client sending a message body &SHOULD; monitor
    31043106   the network connection for an error response while it is transmitting
    3105    the request. If the client sees an error response, it &SHOULD;
    3106    immediately cease transmitting the body and close the connection.
     3107   the request. If the client sees a response that indicates the server does
     3108   not wish to receive the message body and is closing the connection, the
     3109   client &SHOULD; immediately cease transmitting the body and close its side
     3110   of the connection.
    31073111</t>
    31083112</section>
     
    33053309</artwork></figure>
    33063310<t>
    3307   For compatibility with legacy list rules, recipients &MUST; parse and ignore
     3311  For compatibility with legacy list rules, a recipient &MUST; parse and ignore
    33083312  a reasonable number of empty list elements: enough to handle common mistakes
    33093313  by senders that merge values, but not so much that they could be used as a
    3310   denial of service mechanism. In other words, recipients &MUST; expand the
     3314  denial of service mechanism. In other words, a recipient &MUST; expand the
    33113315  list construct as follows:
    33123316</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2401 r2402  
    930930      <p id="rfc.section.3.1.1.3.p.2">MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break. HTTP allows the transfer
    931931         of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation.
    932          HTTP senders <em class="bcp14">MAY</em> generate, and recipients <em class="bcp14">MUST</em> be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is
     932         An HTTP sender <em class="bcp14">MAY</em> generate, and a recipient <em class="bcp14">MUST</em> be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is
    933933         not limited to charsets that use octets 13 and 10 for CR and LF, respectively. This flexibility regarding line breaks applies
    934934         only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or
     
    957957      <div id="rfc.figure.u.6"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    958958</pre><p id="rfc.section.3.1.1.5.p.5">A sender that generates a message containing a payload body <em class="bcp14">SHOULD</em> generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown
    959          to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the data to determine its type.
     959         to the sender. If a Content-Type header field is not present, the recipient <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the data to determine its type.
    960960      </p>
    961961      <p id="rfc.section.3.1.1.5.p.6">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     
    21012101         or their site's security policy.
    21022102      </p>
    2103       <p id="rfc.section.5.5.1.p.6">Robotic user agents <em class="bcp14">SHOULD</em> send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on
     2103      <p id="rfc.section.5.5.1.p.6">A robotic user agent <em class="bcp14">SHOULD</em> send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on
    21042104         servers, such as if the robot is sending excessive, unwanted, or invalid requests.
    21052105      </p>
    2106       <p id="rfc.section.5.5.1.p.7">Servers <em class="bcp14">SHOULD NOT</em> use the From header field for access control or authentication, since most recipients will assume that the field value is
     2106      <p id="rfc.section.5.5.1.p.7">A server <em class="bcp14">SHOULD NOT</em> use the From header field for access control or authentication, since most recipients will assume that the field value is
    21072107         public information.
    21082108      </p>
     
    21312131         Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes
    21322132         to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components.
    2133          Intermediaries <em class="bcp14">SHOULD NOT</em> modify or delete the Referer field when the field value shares the same scheme and host as the request target.
     2133         An intermediary <em class="bcp14">SHOULD NOT</em> modify or delete the Referer header field when the field value shares the same scheme and host as the request target.
    21342134      </p>
    21352135      <div id="rfc.iref.u.1"></div>
     
    21462146      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.user-agent" class="smpl">product</a>         = <a href="#imported.abnf" class="smpl">token</a> ["/" <a href="#header.user-agent" class="smpl">product-version</a>]
    21472147  <a href="#header.user-agent" class="smpl">product-version</a> = <a href="#imported.abnf" class="smpl">token</a>
    2148 </pre><p id="rfc.section.5.5.3.p.5">Senders <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; senders <em class="bcp14">MUST NOT</em> generate advertising or other non-essential information within the product identifier. Senders <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought to only differ in the product-version
     2148</pre><p id="rfc.section.5.5.3.p.5">A sender <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; a sender <em class="bcp14">MUST NOT</em> generate advertising or other non-essential information within the product identifier. A sender <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought to only differ in the product-version
    21492149         portion of the product identifier).
    21502150      </p>
     
    21622162      <p id="rfc.section.6.p.1">The status-code element is a 3-digit integer code giving the result of the attempt to understand and satisfy the request.</p>
    21632163      <p id="rfc.section.6.p.2">HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes,
    2164          though such understanding is obviously desirable. However, clients <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent
     2164         though such understanding is obviously desirable. However, a client <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent
    21652165         to the x00 status code of that class, with the exception that a recipient <em class="bcp14">MUST NOT</em> cache a response with an unrecognized status code.
    21662166      </p>
     
    24182418         the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
    24192419         and thus are terminated by the empty line at the end of the header section. Since HTTP/1.0 did not define any 1xx status codes,
    2420          servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2420         a server <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client.
    24212421      </p>
    24222422      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user
     
    25672567         </p>
    25682568      </div>
    2569       <p id="rfc.section.6.4.p.4">Clients <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
     2569      <p id="rfc.section.6.4.p.4">A client <em class="bcp14">SHOULD</em> detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
    25702570      </p>
    25712571      <div class="note" id="rfc.section.6.4.p.5">
     
    26052605      </p>
    26062606      <div class="note" id="rfc.section.6.4.2.p.3">
    2607          <p><b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> can be used instead.
     2607         <p><b>Note:</b> For historic reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.
    26082608         </p>
    26092609      </div>
     
    26192619      </p>
    26202620      <div class="note" id="rfc.section.6.4.3.p.3">
    2621          <p><b>Note:</b> For historic reasons, user agents <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, status code <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> can be used instead.
     2621         <p><b>Note:</b> For historic reasons, a user agent <em class="bcp14">MAY</em> change the request method from POST to GET for the subsequent request. If this behavior is undesired, the <a href="#status.307" class="smpl">307 (Temporary Redirect)</a> status code can be used instead.
    26222622         </p>
    26232623      </div>
     
    27852785      <p id="rfc.section.6.6.p.1">The <dfn>5xx (Server Error)</dfn> class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method.
    27862786         Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
    2787          User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
     2787         A user agent <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
    27882788      </p>
    27892789      <div id="rfc.iref.72"></div>
     
    39503950         fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by
    39513951         the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so we can assume that fingerprinting
    3952          concerns only apply to situations where cookies are disabled or restricted by browser configuration.
     3952         concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
    39533953      </p>
    39543954      <p id="rfc.section.9.6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics,
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2401 r2402  
    446446   transfer of text media with plain CR or LF alone representing a line
    447447   break, when such line breaks are consistent for an entire representation.
    448    HTTP senders &MAY; generate, and recipients &MUST; be able to parse,
     448   An HTTP sender &MAY; generate, and a recipient &MUST; be able to parse,
    449449   line breaks in text media that consist of CRLF, bare CR, or bare LF.
    450450   In addition, text media in HTTP is not limited to charsets that
     
    507507   generate a Content-Type header field in that message unless the intended
    508508   media type of the enclosed representation is unknown to the sender.
    509    If a Content-Type header field is not present, recipients &MAY; either
     509   If a Content-Type header field is not present, the recipient &MAY; either
    510510   assume a media type of
    511511   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     
    24572457</t>
    24582458<t>
    2459    Robotic user agents &SHOULD; send a valid From header field so that the
     2459   A robotic user agent &SHOULD; send a valid From header field so that the
    24602460   person responsible for running the robot can be contacted if problems
    24612461   occur on servers, such as if the robot is sending excessive, unwanted,
     
    24632463</t>
    24642464<t>
    2465    Servers &SHOULD-NOT; use the From header field for access control or
     2465   A server &SHOULD-NOT; use the From header field for access control or
    24662466   authentication, since most recipients will assume that the field value is
    24672467   public information.
     
    25242524   changes to specific edits, such as replacing internal domain names with
    25252525   pseudonyms or truncating the query and/or path components.
    2526    Intermediaries &SHOULD-NOT; modify or delete the Referer field when the
    2527    field value shares the same scheme and host as the request target.
     2526   An intermediary &SHOULD-NOT; modify or delete the Referer header field when
     2527   the field value shares the same scheme and host as the request target.
    25282528</t>
    25292529</section>
     
    25592559</artwork></figure>
    25602560<t>
    2561    Senders &SHOULD; limit generated product identifiers to what is necessary
    2562    to identify the product; senders &MUST-NOT; generate advertising or other
     2561   A sender &SHOULD; limit generated product identifiers to what is necessary
     2562   to identify the product; a sender &MUST-NOT; generate advertising or other
    25632563   non-essential information within the product identifier.
    2564    Senders &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
     2564   A sender &SHOULD-NOT; generate information in <x:ref>product-version</x:ref>
    25652565   that is not a version identifier (i.e., successive versions of the same
    25662566   product name ought to only differ in the product-version portion of the
     
    26002600   HTTP status codes are extensible. HTTP clients are not required
    26012601   to understand the meaning of all registered status codes, though such
    2602    understanding is obviously desirable. However, clients &MUST;
     2602   understanding is obviously desirable. However, a client &MUST;
    26032603   understand the class of any status code, as indicated by the first
    26042604   digit, and treat an unrecognized status code as being equivalent to the
     
    27252725   fields, and thus are terminated by the empty line at the end of the header
    27262726   section.
    2727    Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    2728    a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2727   Since HTTP/1.0 did not define any 1xx status codes, a server &MUST-NOT; send
     2728   a 1xx response to an HTTP/1.0 client.
    27292729</t>
    27302730<t>
     
    30493049</x:note>
    30503050<t>
    3051    Clients &SHOULD; detect and intervene in cyclical redirections (i.e.,
     3051   A client &SHOULD; detect and intervene in cyclical redirections (i.e.,
    30523052   "infinite" redirection loops).
    30533053</t>
     
    31273127<x:note>
    31283128  <t>
    3129     &Note; For historic reasons, user agents &MAY; change the
     3129    &Note; For historic reasons, a user agent &MAY; change the
    31303130    request method from POST to GET for the subsequent request. If this
    3131     behavior is undesired, status code <x:ref>307 (Temporary Redirect)</x:ref>
    3132     can be used instead.
     3131    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
     3132    status code can be used instead.
    31333133  </t>
    31343134</x:note>
     
    31583158<x:note>
    31593159  <t>
    3160     &Note; For historic reasons, user agents &MAY; change the
     3160    &Note; For historic reasons, a user agent &MAY; change the
    31613161    request method from POST to GET for the subsequent request. If this
    3162     behavior is undesired, status code <x:ref>307 (Temporary Redirect)</x:ref>
    3163     can be used instead.
     3162    behavior is undesired, the <x:ref>307 (Temporary Redirect)</x:ref>
     3163    status code can be used instead.
    31643164  </t>
    31653165</x:note>
     
    35483548   representation containing an explanation of the error situation, and
    35493549   whether it is a temporary or permanent condition.
    3550    User agents &SHOULD; display any included representation to the user.
     3550   A user agent &SHOULD; display any included representation to the user.
    35513551   These response codes are applicable to any request method.
    35523552</t>
     
    50395039   the user. Likewise, Cookie header fields are deliberately designed to
    50405040   enable re-identification, so we can assume that fingerprinting concerns
    5041    only apply to situations where cookies are disabled or restricted by
    5042    browser configuration.
     5041   only apply to situations where cookies are disabled or restricted by the
     5042   user agent's configuration.
    50435043</t>
    50445044<t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2398 r2402  
    719719      <div id="rfc.figure.u.2"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    720720</pre><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="lastmod.generation" href="#lastmod.generation">Generation</a></h3>
    721       <p id="rfc.section.2.2.1.p.1">Origin servers <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined,
     721      <p id="rfc.section.2.2.1.p.1">An origin server <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined,
    722722         since its use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service
    723723         scalability and reliability.
     
    812812         attributes, or a modification timestamp that has sub-second resolution.
    813813      </p>
    814       <p id="rfc.section.2.3.1.p.3">Origin servers <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since
     814      <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since
    815815         the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
    816816         and reliability.
     
    923923      <p id="rfc.section.2.4.p.4">A client: </p>
    924924      <ul>
    925          <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
    926          </li>
    927          <li><em class="bcp14">SHOULD</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in non-subrange cache-conditional requests (using <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>) if only a Last-Modified value has been provided by the origin server.
    928          </li>
    929          <li><em class="bcp14">MAY</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in subrange cache-conditional requests (using <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty.
    930          </li>
    931          <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
     925         <li><em class="bcp14">MUST</em> send that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
     926         </li>
     927         <li><em class="bcp14">SHOULD</em> send the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in non-subrange cache-conditional requests (using <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>) if only a Last-Modified value has been provided by the origin server.
     928         </li>
     929         <li><em class="bcp14">MAY</em> send the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in subrange cache-conditional requests (using <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty.
     930         </li>
     931         <li><em class="bcp14">SHOULD</em> send both validators in cache-conditional requests if both an entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
    932932         </li>
    933933      </ul>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2398 r2402  
    317317<section title="Generation" anchor="lastmod.generation">
    318318<t>
    319    Origin servers &SHOULD; send Last-Modified for any selected
     319   An origin server &SHOULD; send Last-Modified for any selected
    320320   representation for which a last modification date can be reasonably
    321321   and consistently determined, since its use in conditional requests
     
    488488</t>
    489489<t>
    490    Origin servers &SHOULD; send ETag for any selected representation
     490   An origin server &SHOULD; send ETag for any selected representation
    491491   for which detection of changes can be reasonably and consistently
    492492   determined, since the entity-tag's use in conditional requests and
     
    629629   A client:
    630630  <list style="symbols">
    631      <t>&MUST; use that entity-tag in any cache-conditional request (using
     631     <t>&MUST; send that entity-tag in any cache-conditional request (using
    632632        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
    633633        entity-tag has been provided by the origin server.</t>
    634634
    635      <t>&SHOULD; use the <x:ref>Last-Modified</x:ref> value in non-subrange
     635     <t>&SHOULD; send the <x:ref>Last-Modified</x:ref> value in non-subrange
    636636        cache-conditional requests (using <x:ref>If-Modified-Since</x:ref>)
    637637        if only a Last-Modified value has been provided by the origin server.</t>
    638638
    639      <t>&MAY; use the <x:ref>Last-Modified</x:ref> value in subrange
     639     <t>&MAY; send the <x:ref>Last-Modified</x:ref> value in subrange
    640640        cache-conditional requests (using <x:ref>If-Unmodified-Since</x:ref>)
    641641        if only a Last-Modified value has been provided by an HTTP/1.0 origin
     
    643643        of difficulty.</t>
    644644
    645      <t>&SHOULD; use both validators in cache-conditional requests if both an
     645     <t>&SHOULD; send both validators in cache-conditional requests if both an
    646646        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
    647647        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
  • draft-ietf-httpbis/latest/p5-range.html

    r2401 r2402  
    719719      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a>     = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>
    720720  <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> = 1#<a href="#range.units" class="smpl">range-unit</a> / "none"
    721 </pre><p id="rfc.section.2.3.p.3">Origin servers that support byte-range requests <em class="bcp14">MAY</em> send
     721</pre><p id="rfc.section.2.3.p.3">An origin server that supports byte-range requests for a given target resource <em class="bcp14">MAY</em> send
    722722      </p>
    723723      <div id="rfc.figure.u.13"></div><pre class="text">  Accept-Ranges: bytes
    724 </pre><p id="rfc.section.2.3.p.5">but are not required to do so. Clients <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
    725       </p>
    726       <p id="rfc.section.2.3.p.6">Servers that do not support any kind of range request for the target resource resource <em class="bcp14">MAY</em> send
     724</pre><p id="rfc.section.2.3.p.5">to indicate what range units are supported. A client <em class="bcp14">MAY</em> generate range requests without having received this header field for the resource involved. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
     725      </p>
     726      <p id="rfc.section.2.3.p.6">A server that does not support any kind of range request for the target resource resource <em class="bcp14">MAY</em> send
    727727      </p>
    728728      <div id="rfc.figure.u.14"></div><pre class="text">  Accept-Ranges: none
  • draft-ietf-httpbis/latest/p5-range.xml

    r2401 r2402  
    344344</artwork></figure>
    345345<t>
    346    Origin servers that support byte-range requests &MAY; send
     346   An origin server that supports byte-range requests for a given target
     347   resource &MAY; send
    347348</t>
    348349<figure><artwork type="example">
     
    350351</artwork></figure>
    351352<t>
    352    but are not required to do so. Clients &MAY; generate range
     353   to indicate what range units are supported. A client &MAY; generate range
    353354   requests without having received this header field for the resource
    354355   involved. Range units are defined in <xref target="range.units"/>.
    355356</t>
    356357<t>
    357    Servers that do not support any kind of range request for the target
     358   A server that does not support any kind of range request for the target
    358359   resource resource &MAY; send
    359360</t>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2401 r2402  
    697697      <div id="rfc.iref.s.1"></div>
    698698      <div id="rfc.iref.p.1"></div>
    699       <div id="shared.and.non-shared.caches">
     699      <div id="shared.and.private.caches">
    700700         <p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as
    701701            a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user.
     
    720720      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    721721</pre><p id="rfc.section.1.2.1.p.3">If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent
    722          calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> generate delta-seconds with a value greater than 2147483648.
     722         calculations overflows, the cache <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). A recipient parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and a sender <em class="bcp14">MUST NOT</em> generate delta-seconds with a value greater than 2147483648.
    723723      </p>
    724724      <div id="rfc.iref.c.2"></div>
     
    912912      <p id="rfc.section.4.2.p.12"></p>
    913913      <ul>
    914          <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
     914         <li>Although all date formats are specified to be case-sensitive, a cache recipient <em class="bcp14">SHOULD</em> match day, week, and timezone names case-insensitively.
    915915         </li>
    916916         <li>If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient <em class="bcp14">MUST</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as the nearest time equal to or earlier than the received value.
    917917         </li>
    918          <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time.
    919          </li>
    920          <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.
     918         <li>A cache recipient <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time.
     919         </li>
     920         <li>A cache recipient <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.
    921921         </li>
    922922      </ul>
     
    12001200      <p id="rfc.section.5.2.p.5">Cache directives are identified by a token, to be compared case-insensitively, and have an optional argument, that can use
    12011201         both token and quoted-string syntax. For the directives defined below that define arguments, recipients ought to accept both
    1202          forms, even if one is documented to be preferred. For any directive not defined by this specification, recipients <em class="bcp14">MUST</em> accept both forms.
     1202         forms, even if one is documented to be preferred. For any directive not defined by this specification, a recipient <em class="bcp14">MUST</em> accept both forms.
    12031203      </p>
    12041204      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span>  <a href="#header.cache-control" class="smpl">Cache-Control</a>   = 1#<a href="#header.cache-control" class="smpl">cache-directive</a>
     
    12181218         stale response.
    12191219      </p>
    1220       <p id="rfc.section.5.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1220      <p id="rfc.section.5.2.1.1.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. A sender <em class="bcp14">SHOULD NOT</em> generate the quoted-string form.
    12211221      </p>
    12221222      <div id="rfc.iref.m.2"></div>
     
    12321232         to accept a stale response of any age.
    12331233      </p>
    1234       <p id="rfc.section.5.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1234      <p id="rfc.section.5.2.1.2.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. A sender <em class="bcp14">SHOULD NOT</em> generate the quoted-string form.
    12351235      </p>
    12361236      <div id="rfc.iref.m.3"></div>
     
    12451245         for at least the specified number of seconds.
    12461246      </p>
    1247       <p id="rfc.section.5.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1247      <p id="rfc.section.5.2.1.3.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender <em class="bcp14">SHOULD NOT</em> generate the quoted-string form.
    12481248      </p>
    12491249      <div id="rfc.iref.n.1"></div>
     
    13021302         received; i.e., the special handling for the qualified form is not widely implemented.
    13031303      </p>
    1304       <p id="rfc.section.5.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     1304      <p id="rfc.section.5.2.2.2.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. A sender <em class="bcp14">SHOULD NOT</em> generate the token form (even if quoting appears not to be needed for single-entry lists).
    13051305      </p>
    13061306      <div id="rfc.iref.n.5"></div>
     
    13171317      <div id="rfc.iref.p.2"></div>
    13181318      <h4 id="rfc.section.5.2.2.5"><a href="#rfc.section.5.2.2.5">5.2.2.5</a>&nbsp;<a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>
    1319       <p id="rfc.section.5.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
     1319      <p id="rfc.section.5.2.2.5.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a private cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
    13201320         as cacheable.)
    13211321      </p>
     
    13371337         was received; i.e., the special handling for the qualified form is not widely implemented.
    13381338      </p>
    1339       <p id="rfc.section.5.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     1339      <p id="rfc.section.5.2.2.6.p.6"><b>Note:</b> This directive uses the quoted-string form of the argument syntax. A sender <em class="bcp14">SHOULD NOT</em> generate the token form (even if quoting appears not to be needed for single-entry lists).
    13401340      </p>
    13411341      <div id="rfc.iref.p.4"></div>
     
    13541354         number of seconds.
    13551355      </p>
    1356       <p id="rfc.section.5.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1356      <p id="rfc.section.5.2.2.8.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-age=5', not 'max-age="5"'. A sender <em class="bcp14">SHOULD NOT</em> generate the quoted-string form.
    13571357      </p>
    13581358      <div id="rfc.iref.s.4"></div>
     
    13661366         the maximum age specified by either the max-age directive or the <a href="#header.expires" class="smpl">Expires</a> header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
    13671367      </p>
    1368       <p id="rfc.section.5.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     1368      <p id="rfc.section.5.2.2.9.p.3"><b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. A sender <em class="bcp14">SHOULD NOT</em> generate the quoted-string form.
    13691369      </p>
    13701370      <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2401 r2402  
    163163<iref item="shared cache" />
    164164<iref item="private cache" />
    165 <t anchor="shared.and.non-shared.caches">
     165<t anchor="shared.and.private.caches">
    166166   A <x:dfn>shared cache</x:dfn> is a cache that stores responses to be reused
    167167   by more than one user; shared caches are usually (but not always) deployed
     
    214214   If a cache receives a delta-seconds value larger than the largest
    215215   positive integer it can represent, or if any of its subsequent calculations
    216    overflows, it &MUST; consider the value to be 2147483648
    217    (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use
    218    an arithmetic type of at least 31 bits of range, and senders &MUST-NOT;
     216   overflows, the cache &MUST; consider the value to be 2147483648
     217   (2<x:sup>31</x:sup>). A recipient parsing a delta-seconds value &MUST; use
     218   an arithmetic type of at least 31 bits of range, and a sender &MUST-NOT;
    219219   generate delta-seconds with a value greater than 2147483648.
    220220</t>
     
    594594  <list style="symbols">
    595595     <t>Although all date formats are specified to be case-sensitive,
    596         cache recipients &SHOULD; match day, week and timezone names
     596        a cache recipient &SHOULD; match day, week, and timezone names
    597597        case-insensitively.</t>
    598598             
     
    602602        nearest time equal to or earlier than the received value.</t>
    603603
    604      <t>Cache recipients &MUST-NOT; allow local time zones to influence the
     604     <t>A cache recipient &MUST-NOT; allow local time zones to influence the
    605605        calculation or comparison of an age or expiration time.</t>
    606606
    607      <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
     607     <t>A cache recipient &SHOULD; consider a date with a zone abbreviation
    608608        other than GMT or UTC to be invalid for calculating expiration.</t>
    609609  </list>
     
    12091209   syntax. For the directives defined below that define arguments, recipients
    12101210   ought to accept both forms, even if one is documented to be preferred. For
    1211    any directive not defined by this specification, recipients &MUST; accept
     1211   any directive not defined by this specification, a recipient &MUST; accept
    12121212   both forms.
    12131213</t>
     
    12421242<t>
    12431243   &Note; This directive uses the token form of the argument syntax;
    1244    e.g., 'max-age=5', not 'max-age="5"'. Senders &SHOULD-NOT; use the
     1244   e.g., 'max-age=5', not 'max-age="5"'. A sender &SHOULD-NOT; generate the
    12451245   quoted-string form.
    12461246</t>
     
    12671267<t>
    12681268   &Note; This directive uses the token form of the argument syntax;
    1269    e.g., 'max-stale=10', not 'max-stale="10"'. Senders &SHOULD-NOT; use the
    1270    quoted-string form.
     1269   e.g., 'max-stale=10', not 'max-stale="10"'. A sender &SHOULD-NOT; generate
     1270   the quoted-string form.
    12711271</t>
    12721272</section>
     
    12911291<t>
    12921292   &Note; This directive uses the token form of the argument syntax;
    1293    e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders &SHOULD-NOT; use the
    1294    quoted-string form.
     1293   e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender &SHOULD-NOT; generate
     1294   the quoted-string form.
    12951295</t>
    12961296</section>
     
    14181418<t>
    14191419   &Note; This directive uses the quoted-string form of the argument syntax.
    1420    Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
    1421    needed for single-entry lists).
     1420   A sender &SHOULD-NOT; generate the token form (even if quoting appears not
     1421   to be needed for single-entry lists).
    14221422</t>
    14231423</section>
     
    14561456   The "public" response directive indicates that any cache &MAY; store the
    14571457   response, even if the response would normally be non-cacheable or cacheable
    1458    only within a non-shared cache. (See <xref
     1458   only within a private cache. (See <xref
    14591459   target="caching.authenticated.responses"/> for additional details related
    14601460   to the use of public in response to a request containing
     
    15021502<t>
    15031503   &Note; This directive uses the quoted-string form of the argument syntax.
    1504    Senders &SHOULD-NOT; use the token form (even if quoting appears not to be
    1505    needed for single-entry lists).
     1504   A sender &SHOULD-NOT; generate the token form (even if quoting appears not
     1505   to be needed for single-entry lists).
    15061506</t>
    15071507</section>
     
    15331533<t>
    15341534   &Note; This directive uses the token form of the argument syntax;
    1535    e.g., 'max-age=5', not 'max-age="5"'. Senders &SHOULD-NOT; use the
     1535   e.g., 'max-age=5', not 'max-age="5"'. A sender &SHOULD-NOT; generate the
    15361536   quoted-string form.
    15371537</t>
     
    15571557<t>
    15581558   &Note; This directive uses the token form of the argument syntax;
    1559    e.g., 's-maxage=10', not 's-maxage="10"'. Senders &SHOULD-NOT; use the
    1560    quoted-string form.
     1559   e.g., 's-maxage=10', not 's-maxage="10"'. A sender &SHOULD-NOT; generate
     1560   the quoted-string form.
    15611561</t>
    15621562</section>
  • draft-ietf-httpbis/latest/p7-auth.html

    r2399 r2402  
    689689         authentication information. However, such additional mechanisms are not defined by this specification.
    690690      </p>
    691       <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     691      <p id="rfc.section.2.1.p.18">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
    692692      </p>
    693693      <div id="rfc.iref.p.1"></div>
     
    702702      </p>
    703703      <p id="rfc.section.2.2.p.3">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
    704          authorized, the same credentials <em class="bcp14">MAY</em> be reused for all other requests within that protection space for a period of time determined by the authentication scheme,
    705          parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection space cannot
    706          extend outside the scope of its server.
    707       </p>
    708       <p id="rfc.section.2.2.p.4">For historical reasons, senders <em class="bcp14">MUST</em> only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability
     704         authorized, the user agent <em class="bcp14">MAY</em> reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication
     705         scheme, parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection
     706         space cannot extend outside the scope of its server.
     707      </p>
     708      <p id="rfc.section.2.2.p.4">For historical reasons, a sender <em class="bcp14">MUST</em> only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability
    709709         with existing clients that have been accepting both notations for a long time.
    710710      </p>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2399 r2402  
    270270</t>
    271271<t>
    272    Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
     272   A proxy &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
    273273   <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
    274274   found in <xref target="header.authorization"/>.
     
    300300   The protection space determines the domain over which credentials can
    301301   be automatically applied. If a prior request has been authorized, the
    302    same credentials &MAY; be reused for all other requests within that
    303    protection space for a period of time determined by the
     302   user agent &MAY; reuse the same credentials for all other requests within
     303   that protection space for a period of time determined by the
    304304   authentication scheme, parameters, and/or user preference. Unless
    305305   specifically allowed by the authentication scheme, a single protection
     
    307307</t>
    308308<t>
    309    For historical reasons, senders &MUST; only generate the quoted-string syntax.
     309   For historical reasons, a sender &MUST; only generate the quoted-string syntax.
    310310   Recipients might have to support both token and quoted-string syntax for
    311311   maximum interoperability with existing clients that have been accepting both
Note: See TracChangeset for help on using the changeset viewer.