UPGRADE: s/subresource/non-navigational/ (#226)

Author: mikewest

specs/upgrade/index.html

@@ -71,7 +71,7 @@
    <h1 class="p-name no-ref" id="title">Upgrade Insecure Requests</h1>
 
    <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft,
-    <time class="dt-updated" datetime="2015-07-15">15 July 2015</time></span></h2>
+    <time class="dt-updated" datetime="2015-07-16">16 July 2015</time></span></h2>
 
    <div data-fill-with="spec-metadata">
     <dl>
@@ -169,7 +169,7 @@ <h2 class="no-num no-toc no-ref heading settled" id="contents"><span class="cont
       <li><a href="#goals"><span class="secno">1.1</span> <span class="content">Goals</span></a>
       <li><a href="#examples"><span class="secno">1.2</span> <span class="content">Examples</span></a>
        <ul class="toc">
-        <li><a href="#example-subresource"><span class="secno">1.2.1</span> <span class="content">Subresource Upgrades</span></a>
+        <li><a href="#example-nonnavigational"><span class="secno">1.2.1</span> <span class="content">Non-navigational Upgrades</span></a>
         <li><a href="#example-navigation"><span class="secno">1.2.2</span> <span class="content">Navigational Upgrades</span></a>
         <li><a href="#example-failed"><span class="secno">1.2.3</span> <span class="content">Failed Upgrade</span></a>
        </ul>
@@ -267,7 +267,7 @@ <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </s
     <p>Most notably, mixed content checking <a data-link-type="biblio" href="#biblio-mix">[MIX]</a> has the potential to cause real
   headache for administrators tasked with moving substantial amounts of legacy
   content onto HTTPS. In particular, going through old content and rewriting
-  subresource URLs manually is a huge undertaking. Moreover, it’s often the case
+  resource URLs manually is a huge undertaking. Moreover, it’s often the case
   that truly legacy content is difficult or impossible to update. Consider the
   BBC’s archived websites <a data-link-type="biblio" href="#biblio-bbc-archive">[BBC-ARCHIVE]</a>, or the New York Times' hard-coded
   URLs <a data-link-type="biblio" href="#biblio-nyt-https">[NYT-HTTPS]</a>.</p>
@@ -355,10 +355,10 @@ <h3 class="heading settled" data-level="1.1" id="goals"><span class="secno">1.1.
     <h3 class="heading settled" data-level="1.2" id="examples"><span class="secno">1.2. </span><span class="content">Examples</span><a class="self-link" href="#examples"></a></h3>
 
 
-    <h4 class="heading settled" data-level="1.2.1" id="example-subresource"><span class="secno">1.2.1. </span><span class="content">Subresource Upgrades</span><a class="self-link" href="#example-subresource"></a></h4>
+    <h4 class="heading settled" data-level="1.2.1" id="example-nonnavigational"><span class="secno">1.2.1. </span><span class="content">Non-navigational Upgrades</span><a class="self-link" href="#example-nonnavigational"></a></h4>
 
 
-    <div class="example" id="example-35db2d27"><a class="self-link" href="#example-35db2d27"></a>
+    <div class="example" id="example-40296e80"><a class="self-link" href="#example-40296e80"></a>
     Megacorp, Inc. wishes to migrate <code>http://example.com/</code> to
     <code>https://example.com</code>. They set up their servers
     to make their own resources available over HTTPS, and work with partners in
@@ -406,7 +406,7 @@ <h4 class="heading settled" data-level="1.2.1" id="example-subresource"><span cl
 
      <p>The URL will be rewritten before the request is made, meaning that no
     insecure requests will hit the network. Users will be safer, and Megacorp’s
-    administrators will be happier, as all subresource requests will be
+    administrators will be happier, as all resource requests will be
     transparently upgraded with no effort on their part.</p>
 
 
@@ -466,7 +466,7 @@ <h4 class="heading settled" data-level="1.2.2" id="example-navigation"><span cla
     <h4 class="heading settled" data-level="1.2.3" id="example-failed"><span class="secno">1.2.3. </span><span class="content">Failed Upgrade</span><a class="self-link" href="#example-failed"></a></h4>
 
 
-    <div class="example" id="example-962745f2"><a class="self-link" href="#example-962745f2"></a>
+    <div class="example" id="example-2437e019"><a class="self-link" href="#example-2437e019"></a>
     Tinycorp, Inc. enabled <code><a data-link-type="dfn" href="#upgrade_insecure_requests">upgrade-insecure-requests</a></code> a bit
     earlier than they should have, as they don’t actually support HTTPS on
     <code>http://cdn.example.com/</code>. Given the following code:
@@ -477,7 +477,7 @@ <h4 class="heading settled" data-level="1.2.3" id="example-failed"><span class="
 
 
 
-     <p>User agents will upgrade requests, as described in <a href="#example-subresource">§1.2.1 Subresource Upgrades</a>,
+     <p>User agents will upgrade requests, as described in <a href="#example-nonnavigational">§1.2.1 Non-navigational Upgrades</a>,
     rewriting the URL as <code>https://cdn.example.com/image.png</code>. As the
     server doesn’t respond to secure requests, this results in a network error.</p>
 
@@ -732,8 +732,7 @@ <h2 class="heading settled" data-level="2" id="key-concepts"><span class="secno"
 
 </dl>
 
-    <p>The Augmented Backus-Naur Form (ABNF) notation used in <a href="#delivery">§3.1 
-    The upgrade-insecure-requests Content Security Policy directive</a> is
+    <p>The Augmented Backus-Naur Form (ABNF) notation used in <a href="#delivery">§3.1 The upgrade-insecure-requests Content Security Policy directive</a> is
   specified in RFC5234. <a data-link-type="biblio" href="#biblio-abnf">[ABNF]</a></p>
 </section>
 
@@ -762,9 +761,8 @@ <h2 class="heading settled" data-level="3" id="upgrading"><span class="secno">3.
       Upgrade<a class="self-link" href="#valdef-insecure-requests-policy-do-not-upgrade"></a></dfn> and
       <dfn class="css" data-dfn-for="insecure requests policy" data-dfn-type="value" data-export="" id="valdef-insecure-requests-policy-upgrade">Upgrade<a class="self-link" href="#valdef-insecure-requests-policy-upgrade"></a></dfn>. It is
       set to <a class="css" data-link-type="value" href="#valdef-insecure-requests-policy-do-not-upgrade">Do Not Upgrade</a> unless otherwise specified. This policy
-      is checked in <a href="#upgrade-request">§4.1 
-    Upgrade request to a potentially secure URL, if appropriate</a> in order to determine whether or not
-      subresource requests and form submissions should be upgraded during
+      is checked in <a href="#upgrade-request">§4.1 Upgrade request to a potentially secure URL, if appropriate</a> in order to determine whether or not
+      non-navigational requests and form submissions should be upgraded during
       <a data-link-type="dfn" href="https://fetch.spec.whatwg.org/#fetching">fetching</a>.
 
 
@@ -774,8 +772,7 @@ <h2 class="heading settled" data-level="3" id="upgrading"><span class="secno">3.
       given an <dfn data-dfn-type="dfn" data-export="" id="upgrade-insecure-navigations-set">upgrade insecure navigations set<a class="self-link" href="#upgrade-insecure-navigations-set"></a></dfn> which
       contains a set of (<code class="idl"><a data-link-type="idl" href="http://www.w3.org/TR/url/#concept-url-host">host</a></code>, <code class="idl"><a data-link-type="idl" href="http://www.w3.org/TR/url/#concept-url-port">port</a></code>) tuples to which navigations
       ought to be upgraded. Its value is the empty set unless otherwise
-      specified. This set is checked in <a href="#upgrade-request">§4.1 
-    Upgrade request to a potentially secure URL, if appropriate</a> in order to
+      specified. This set is checked in <a href="#upgrade-request">§4.1 Upgrade request to a potentially secure URL, if appropriate</a> in order to
       determine whether or not navigational requests should be upgraded.
 
 
@@ -856,8 +853,7 @@ <h4 class="heading settled" data-level="3.1.1" id="mix"><span class="secno">3.1.
 
     <p>The <code><a data-link-type="dfn" href="#upgrade_insecure_requests">upgrade-insecure-requests</a></code> directive results in
   requests being rewritten at the top of the <a data-link-type="dfn" href="https://fetch.spec.whatwg.org/#fetching">Fetching</a> algorithm
-  <a data-link-type="biblio" href="#biblio-fetch">[FETCH]</a>, as specified in <a href="#upgrade-request">§4.1 
-    Upgrade request to a potentially secure URL, if appropriate</a>. It’s important to note that
+  <a data-link-type="biblio" href="#biblio-fetch">[FETCH]</a>, as specified in <a href="#upgrade-request">§4.1 Upgrade request to a potentially secure URL, if appropriate</a>. It’s important to note that
   the rewrite happens <em>before</em> either Mixed Content <a data-link-type="biblio" href="#biblio-mix">[MIX]</a> or Content
   Security Policy checks take effect <a data-link-type="biblio" href="#biblio-csp2">[CSP2]</a>.</p>
 
@@ -888,8 +884,7 @@ <h3 class="heading settled" data-level="3.2" id="feature-detect"><span class="se
     <p>Rather than relying on user-agent sniffing to make this decision, user agents
   can advertise their upgrade capability when making navigational requests by
   including an <a data-link-type="dfn" href="#upgrade_insecure_requests-http-request-header-field"><code>Upgrade-Insecure-Requests</code> header field</a> as
-  described in <a href="#preference">§3.2.1 
-    The Upgrade-Insecure-Requests HTTP Request Header Field</a>.</p>
+  described in <a href="#preference">§3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field</a>.</p>
 
 
     <h4 class="heading settled" data-level="3.2.1" id="preference"><span class="secno">3.2.1. </span><span class="content">
@@ -920,8 +915,7 @@ <h4 class="heading settled" data-level="3.2.1" id="preference"><span class="secn
 
 
     <p>User agent conformance details are described in step #1 of the the
-  <a href="#upgrade-request">§4.1 
-    Upgrade request to a potentially secure URL, if appropriate</a> algorithm. That step represents the following
+  <a href="#upgrade-request">§4.1 Upgrade request to a potentially secure URL, if appropriate</a> algorithm. That step represents the following
   requirements:</p>
 
 
@@ -1290,8 +1284,7 @@ <h3 class="heading settled" data-level="4.1" id="upgrade-request"><span class="s
 
       <p class="note" role="note">Note: User agents can choose to append the
       <a data-link-type="dfn" href="#upgrade_insecure_requests-http-request-header-field"><code>Upgrade-Insecure-Requests</code> header field</a> for other
-      requests, as discussed in <a href="#preference">§3.2.1 
-    The Upgrade-Insecure-Requests HTTP Request Header Field</a>.</p>
+      requests, as discussed in <a href="#preference">§3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field</a>.</p>
 
 
 
@@ -1344,8 +1337,7 @@ <h3 class="heading settled" data-level="4.1" id="upgrade-request"><span class="s
 
      <li>
       Let <var>upgrade state</var> be the result of executing
-      <a href="#should-upgrade-for-client">§4.2 
-    Should insecure Requests be upgraded for client?</a> upon <var>request</var>’s
+      <a href="#should-upgrade-for-client">§4.2 Should insecure Requests be upgraded for client?</a> upon <var>request</var>’s
       <code class="idl"><a data-link-type="idl" href="https://fetch.spec.whatwg.org/#concept-request-client">client</a></code>.
 
 
@@ -1468,8 +1460,7 @@ <h2 class="heading settled" data-level="5" id="websockets-integration"><span cla
 
          <li>
               Let <var>upgrade state</var> be the result of executing
-              <a href="#should-upgrade-for-client">§4.2 
-    Should insecure Requests be upgraded for client?</a> upon the
+              <a href="#should-upgrade-for-client">§4.2 Should insecure Requests be upgraded for client?</a> upon the
               <a data-link-type="dfn" href="http://www.w3.org/TR/html5/webappapis.html#relevant-settings-object-for-a-script">relevant settings
               object</a> for <var>client</var>’s <var>entry script</var>.
 
@@ -1561,8 +1552,7 @@ <h2 class="heading settled" data-level="7" id="performance"><span class="secno">
   1\r\n</code> to every outgoing navigational request to non-<a data-link-type="dfn" href="#preloadable-hsts-host">preloadable
   HSTS hosts</a> (as discussed at length on public-webappsec@, and
   <a href="https://github.com/w3c/webappsec/issues/216">w3c/webappsec#216</a>).
-  The advantages and intent of the header are laid out in <a href="#preference">§3.2.1 
-    The Upgrade-Insecure-Requests HTTP Request Header Field</a>, and
+  The advantages and intent of the header are laid out in <a href="#preference">§3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field</a>, and
   though we’ve taken some steps to ensure that it won’t be a permanent fixture
   of the platform (by carving out <a data-link-type="dfn" href="#preloadable-hsts-host">preloadable HSTS hosts</a>), it’s going
   to be a long, long time before the header vanishes.</p>
@@ -1663,8 +1653,7 @@ <h3 class="heading settled" data-level="9.1" id="iana-https"><span class="secno"
      <dt>Specification document
 
 
-     <dd>This specification (See <a href="#preference">§3.2.1 
-    The Upgrade-Insecure-Requests HTTP Request Header Field</a>)
+     <dd>This specification (See <a href="#preference">§3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field</a>)
 
 
     </dl>

specs/upgrade/index.src.html

@@ -177,7 +177,7 @@ <h2 id="intro">Introduction</h2>
   Most notably, mixed content checking [[MIX]] has the potential to cause real
   headache for administrators tasked with moving substantial amounts of legacy
   content onto HTTPS. In particular, going through old content and rewriting
-  subresource URLs manually is a huge undertaking. Moreover, it's often the case
+  resource URLs manually is a huge undertaking. Moreover, it's often the case
   that truly legacy content is difficult or impossible to update. Consider the
   BBC's archived websites [[BBC-ARCHIVE]], or the New York Times' hard-coded
   URLs [[NYT-HTTPS]].
@@ -243,7 +243,7 @@ <h3 id="goals">Goals</h3>
 
   <h3 id="examples">Examples</h3>
 
-  <h4 id="example-subresource">Subresource Upgrades</h4>
+  <h4 id="example-nonnavigational">Non-navigational Upgrades</h4>
 
   <div class="example">
     Megacorp, Inc. wishes to migrate <code>http://example.com/</code> to
@@ -281,7 +281,7 @@ <h4 id="example-subresource">Subresource Upgrades</h4>
 
     The URL will be rewritten before the request is made, meaning that no
     insecure requests will hit the network. Users will be safer, and Megacorp's
-    administrators will be happier, as all subresource requests will be
+    administrators will be happier, as all resource requests will be
     transparently upgraded with no effort on their part.
   </div>
 
@@ -311,7 +311,7 @@ <h4 id="example-navigation">Navigational Upgrades</h4>
     </pre>
 
     Links to third-party sites will not be upgraded. That is, the following
-    HTML code: 
+    HTML code:
 
     <pre>
       &lt;a href="http://not-example.com/"&gt;Home&lt;/a&gt;
@@ -326,12 +326,12 @@ <h4 id="example-failed">Failed Upgrade</h4>
     Tinycorp, Inc. enabled <code><a>upgrade-insecure-requests</a></code> a bit
     earlier than they should have, as they don't actually support HTTPS on
     <code>http://cdn.example.com/</code>. Given the following code:
-    
+
     <pre>
       &lt;img src="http://cdn.example.com/image.png"&gt;
     </pre>
 
-    User agents will upgrade requests, as described in [[#example-subresource]],
+    User agents will upgrade requests, as described in [[#example-nonnavigational]],
     rewriting the URL as <code>https://cdn.example.com/image.png</code>. As the
     server doesn't respond to secure requests, this results in a network error.
 
@@ -536,7 +536,7 @@ <h2 id="upgrading">Upgrading Insecure Resource Requests</h2>
       <dfn for="insecure requests policy" value export>Upgrade</dfn>. It is
       set to <a value>Do Not Upgrade</a> unless otherwise specified. This policy
       is checked in [[#upgrade-request]] in order to determine whether or not
-      subresource requests and form submissions should be upgraded during
+      non-navigational requests and form submissions should be upgraded during
       <a>fetching</a>.
     </li>
     <li>