diff --git a/specs/upgrade/index.html b/specs/upgrade/index.html index 5c7fb36f..00d66ac5 100644 --- a/specs/upgrade/index.html +++ b/specs/upgrade/index.html @@ -70,8 +70,8 @@

Upgrade Insecure Requests

-

Editor’s Draft -

+

Editor’s Draft, +

@@ -82,8 +82,9 @@

http://www.w3.org/TR/2015/WD-upgrade-insecure-requests-20150226/
Feedback: -
public-webappsec@w3.org with subject line “[upgrade-insecure-requests] … message topic …” (archives) +
public-webappsec@w3.org with subject line “[upgrade-insecure-requests] … message topic …” (archives)
Issue Tracking: +
GitHub
Inline In Spec
Editor:
(Google Inc.) @@ -181,7 +182,7 @@

3.2 Feature Detecting Clients Capable of Upgrading
  • 3.3 Policy Inheritance @@ -211,7 +212,7 @@

    9 IANA Considerations
  • 10 Acknowledgements @@ -292,9 +293,9 @@

    1.1.

    If we assume that authors do the server-side legwork (obtaining a certificate, configuring the server, setting up redirects), and that authors also ensure - that content is accessible at the same host and path - on a secure scheme, then the following statements ought to hold after - implementing this feature:

    + that both first- and third-party content is accessible at the same + host and path on a secure scheme, then the + following statements ought to hold after implementing this feature:

      @@ -466,13 +467,13 @@

      +
      In Nginx, this kind of redirection might look like this: 
      server {
-  if ($http_https = "1") {
-    add_header Vary HTTPS;
+  if ($http_upgrade_insecure_requests = "1") {
+    add_header Vary Upgrade-Insecure-Requests;
     return 307 https://$host$request_uri;
   }
 }
@@ -608,7 +609,7 @@ 
      
      
      
-      
      upgrade
      
+      
      upgrade
      
       
 
      
      
@@ -627,8 +628,9 @@ 
      resource representation which will be returned does not require the
   upgrade-insecure-requests mechanism described in this
   document to avoid breakage, or if the Request's
-  header-list contains an HTTPS header field
-  with a value of 1.
      
+  header-list contains an
+  Upgrade-Insecure-Requests header field with a value of
+  1.
      
       
 
 
@@ -693,8 +695,7 @@ 
      
 
     
      The Augmented Backus-Naur Form (ABNF) notation used in §3.1 
-    The upgrade-insecure-requests Content Security Policy directive
-   is
+    The upgrade-insecure-requests Content Security Policy directive is
   specified in RFC5234. [ABNF]
      
 
 
@@ -724,8 +725,7 @@ 
      3.
       Upgrade. It is
       set to Do Not Upgrade unless otherwise specified. This policy
       is checked in §4.1 
-    Upgrade request to a potentially secure URL, if appropriate
-   in order to determine whether or not
+    Upgrade request to a potentially secure URL, if appropriate in order to determine whether or not
       subresource requests and form submissions should be upgraded during
       fetching.
     
@@ -737,8 +737,7 @@ 
      3.
       contains a set of (host, port) tuples to which navigations
       ought to be upgraded. Its value is the empty set unless otherwise
       specified. This set is checked in §4.1 
-    Upgrade request to a potentially secure URL, if appropriate
-   in order to
+    Upgrade request to a potentially secure URL, if appropriate in order to
       determine whether or not navigational requests should be upgraded.
     
      
@@ -805,7 +804,7 @@ 
      3
   for additional detail.
      
 
 
-    
      In
+    
       In
   a thread on public-webappsec@,
   Peter Eckersley suggested modifying this to allow whitelisting specific hosts,
   rather than upgrading everything: "That way, if you have N third parties
@@ -820,8 +819,7 @@ 
      3.1.
     
      The upgrade-insecure-requests directive results in
   requests being rewritten at the top of the Fetching algorithm
   [FETCH], as specified in §4.1 
-    Upgrade request to a potentially secure URL, if appropriate
-  . It’s important to note that
+    Upgrade request to a potentially secure URL, if appropriate. It’s important to note that
   the rewrite happens before either Mixed Content [MIX] or Content
   Security Policy checks take effect [CSP2].
      
 
@@ -851,19 +849,19 @@
      -

      HTTPS is listed in the Vary header, - as the redirect response might otherwise be served by caches to clients that +

      The Upgrade-Insecure-Requests + header field is listed in the Vary header, as the + redirect response might otherwise be served by caches to clients that don’t support the upgrade mechanism defined here. A similar effect could be achieved by making this redirect response uncachable via the Cache-Control header:

      @@ -1126,7 +1126,7 @@

      3. -

      Monkey patching. :(

      +

      Monkey patching. :(

      @@ -1134,7 +1134,7 @@

      3.

    -

    The WHATWG HTML spec is significantly clearer here than [WORKERS]. +

    The WHATWG HTML spec is significantly clearer here than [WORKERS]. Hope that doesn’t cause problems when transitioning to CR.

    @@ -1208,9 +1208,10 @@

    Request request, this algorithm will rewrite its url if the client from which the request originates - has opted-in to upgrades. It will also inject an HTTPS - header for insecure navigational requests in order to improve a server’s - ability to feature-detect a client’s upgrade capabilities.

    + has opted-in to upgrades. It will also inject an + Upgrade-Insecure-Requests header field header for + insecure navigational requests in order to improve a server’s ability to + feature-detect a client’s upgrade capabilities.

    We will not upgrade cross-origin navigational requests, with the exception of @@ -1226,8 +1227,8 @@

    context-frame-type is top-level, nested, or auxiliary, - append a header named HTTPS with a value of - 1 to request’s header-list if + append a header named Upgrade-Insecure-Requests with a + value of 1 to request’s header-list if any of the following criteria are met: @@ -1249,10 +1250,10 @@

    Note: User agents can choose to append the HTTPS - header for other requests, as discussed in §3.2.1 - The HTTPS HTTP Request Header Field - .

    +

    Note: User agents can choose to append the + Upgrade-Insecure-Requests header field for other + requests, as discussed in §3.2.1 + The Upgrade-Insecure-Requests HTTP Request Header Field.

    @@ -1306,8 +1307,7 @@

    §4.2 - Should insecure Requests be upgraded for client? - upon request’s + Should insecure Requests be upgraded for client? upon request’s client. @@ -1431,8 +1431,7 @@

    Let upgrade state be the result of executing §4.2 - Should insecure Requests be upgraded for client? - upon the + Should insecure Requests be upgraded for client? upon the relevant settings object for client’s entry script. @@ -1520,13 +1519,12 @@

    7. Performance Considerations

    -

    The upgrade mechanism specified here adds HTTPS: 1\r\n (10 bytes) - to every outgoing navigational request to non-preloadable HSTS hosts - (as discussed at length on public-webappsec@, and +

    The upgrade mechanism specified here adds Upgrade-Insecure-Requests: + 1\r\n to every outgoing navigational request to non-preloadable + HSTS hosts (as discussed at length on public-webappsec@, and w3c/webappsec#216). The advantages and intent of the header are laid out in §3.2.1 - The HTTPS HTTP Request Header Field - , and + The Upgrade-Insecure-Requests HTTP Request Header Field, and though we’ve taken some steps to ensure that it won’t be a permanent fixture of the platform (by carving out preloadable HSTS hosts), it’s going to be a long, long time before the header vanishes.

    @@ -1590,7 +1588,7 @@

    9.1. - HTTPS + Upgrade-Insecure-Requests

    @@ -1599,7 +1597,7 @@

    Header field name -
    HTTPS +
    Upgrade-Insecure-Requests @@ -1628,8 +1626,7 @@

    This specification (See §3.2.1 - The HTTPS HTTP Request Header Field - ) + The Upgrade-Insecure-Requests HTTP Request Header Field)

    • @@ -1726,17 +1723,17 @@

    3
  • HSTS-safe, 2
  • HSTS-safe origin, 2 -
  • HTTPS, 3.2.1 -
  • HTTPS HTTP request header - field, 3.2.1
  • insecure requests policy, 3
  • preloadable HSTS host, 2
  • safely upgradable, 2
  • safely upgradable requests, 2 -
  • upgrade, 2
  • Upgrade, 3 +
  • upgrade a request, 2
  • upgrade insecure navigations set, 3 -
  • upgrade-insecure-requests, 3.1 +
  • upgrade-insecure-requests, 3.1 +
  • Upgrade-Insecure-Requests header field, 3.2.1 +
  • Upgrade-Insecure-Requests HTTP request header + field, 3.2.1

    Terms defined by reference