Changeset 2396

Timestamp:

14/09/13 20:24:52 (7 years ago)

Author:

fielding@…

Message:

strengthen requirements on Referrer, rfc850-date, and Location fragment inheritance; addresses #475

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (3 diffs)
• p2-semantics.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -2125 +2125 @@
          is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource
          that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user
-         agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">SHOULD NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section&nbsp;9.3</a> for additional security considerations.
+         agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent <em class="bcp14">MUST NOT</em> send a <a href="#header.referer" class="smpl">Referer</a> header field in an unsecured HTTP request if the referring page was received with a secure protocol. See <a href="#sensitive.information.in.uris" title="Sensitive Information in URIs">Section&nbsp;9.3</a> for additional security considerations.
       </p>
       <p id="rfc.section.5.5.2.p.8">Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the
@@ -2960 +2960 @@
 </pre><p id="rfc.section.7.1.1.1.p.13">HTTP-date is case sensitive. A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the Internet Message Format constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
       </p>
-      <p id="rfc.section.7.1.1.1.p.14">Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, <em class="bcp14">SHOULD</em> interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past
+      <p id="rfc.section.7.1.1.1.p.14">Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, <em class="bcp14">MUST</em> interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past
          that had the same last two digits.
       </p>
@@ -3004 +3004 @@
       <p id="rfc.section.7.1.2.p.4">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location value refers to the primary resource created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the Location value refers to the preferred target resource for automatically redirecting the request.
       </p>
-      <p id="rfc.section.7.1.2.p.5">When Location is provided in a <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response and the URI reference that the user agent used to generate the request target contains a fragment identifier, the
-         user agent <em class="bcp14">SHOULD</em> process the redirection as if the Location field value inherits the original fragment. In other words, if the Location does
-         not have a fragment component, the user agent <em class="bcp14">SHOULD</em> interpret the Location reference as if it had the original reference's fragment.
+      <p id="rfc.section.7.1.2.p.5">If the Location value provided in a <a href="#status.3xx" class="smpl">3xx (Redirection)</a> does not have a fragment component, a user agent <em class="bcp14">MUST</em> process the redirection as if the value inherits the fragment component of the URI reference used to generate the request
+         target (i.e., the redirection inherits the original reference's fragment, if any).
       </p>
       <div id="rfc.figure.u.53"></div>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -2510 +2510 @@
    behind a firewall or internal to a secured service). Most general-purpose
    user agents do not send the Referer header field when the referring
-   resource is a local "file" or "data" URI. A user agent &SHOULD-NOT; send a
+   resource is a local "file" or "data" URI. A user agent &MUST-NOT; send a
    <x:ref>Referer</x:ref> header field in an unsecured HTTP request if the
    referring page was received with a secure protocol.
@@ -3800 +3800 @@
 <t>
    Recipients of a timestamp value in rfc850-date format, which uses a
-   two-digit year, &SHOULD; interpret a timestamp that appears to be more
+   two-digit year, &MUST; interpret a timestamp that appears to be more
    than 50 years in the future as representing the most recent year in the
    past that had the same last two digits.
@@ -3895 +3895 @@
 </t>
 <t>
-   When Location is provided in a <x:ref>3xx (Redirection)</x:ref> response
-   and the URI reference that the user agent used to generate the request
-   target contains a fragment identifier, the user agent &SHOULD; process the
-   redirection as if the Location field value inherits the original fragment.
-   In other words, if the Location does not have a fragment component, the
-   user agent &SHOULD; interpret the Location reference as if it had the
-   original reference's fragment.
+   If the Location value provided in a <x:ref>3xx (Redirection)</x:ref>
+   does not have a fragment component, a user agent &MUST; process the
+   redirection as if the value inherits the fragment component of the URI
+   reference used to generate the request target (i.e., the redirection
+   inherits the original reference's fragment, if any).
 </t>
 <figure>