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/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,
Note: See TracChangeset for help on using the changeset viewer.