SRI: use HTTPS in external links where we can

Author: Francois Marier

specs/subresourceintegrity/spec.markdown

@@ -54,7 +54,7 @@ Scripts, of course, are not the only response type which would benefit
 from integrity validation. The scheme specified here also applies to `link`
 and future versions of the specification are likely to expand this coverage.
 
-[HSTS]: http://tools.ietf.org/html/rfc6797
+[HSTS]: https://tools.ietf.org/html/rfc6797
 [pinned public keys]: https://tools.ietf.org/html/rfc7469
 
 <section>
@@ -145,17 +145,17 @@ is an origin whose scheme component is <code>HTTPS</code>.
 The <dfn>message body</dfn> and the <dfn>transfer encoding</dfn> of a resource
 are defined by [RFC7230, section 3][messagebody]. [[!RFC7230]] 
 
-[messagebody]: http://tools.ietf.org/html/rfc7230#section-3
+[messagebody]: https://tools.ietf.org/html/rfc7230#section-3
 
 The <dfn>representation data</dfn> and <dfn>content encoding</dfn> of a resource
 are defined by [RFC7231, section 3][representationdata]. [[!RFC7231]]
 
-[representationdata]: http://tools.ietf.org/html/rfc7231#section-3
+[representationdata]: https://tools.ietf.org/html/rfc7231#section-3
 
 A <dfn>base64 encoding</dfn> is defined in [RFC 4648, section 4][base64].
 [[!RFC4648]]
 
-[base64]: http://tools.ietf.org/html/rfc4648#section-4
+[base64]: https://tools.ietf.org/html/rfc4648#section-4
 
 The <dfn>SHA-256</dfn>, <dfn>SHA-384</dfn>, and <dfn>SHA-512</dfn> are part
 of the <dfn>SHA-2</dfn> set of cryptographic hash functions defined by the
@@ -224,7 +224,7 @@ result of the following command line:
     echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64 -A
 
 [csp2-section42]: http://www.w3.org/TR/CSP2/#source-list-syntax
-[openssl]: http://www.openssl.org/
+[openssl]: https://www.openssl.org/
 </div>
 
 [sha2]: #dfn-sha-2
@@ -341,7 +341,7 @@ only deliver integrity metadata on a [potentially secure origin][].  See
 
 {:.note}
 
-[uri-origin]: http://tools.ietf.org/html/rfc6454#section-4
+[uri-origin]: https://tools.ietf.org/html/rfc6454#section-4
 [Non-secure contexts remain non-secure]: #non-secure-contexts-remain-non-secure
 
 The following algorithm details these restrictions:
@@ -359,8 +359,8 @@ fetch failed the CORS checks, it won't be available to us for integrity
 checking because it won't have loaded successfully.
 {:.note}
 
-[fetch-mode]: http://fetch.spec.whatwg.org/#concept-request-mode
-[fetch-origin]: http://fetch.spec.whatwg.org/#concept-request-origin
+[fetch-mode]: https://fetch.spec.whatwg.org/#concept-request-mode
+[fetch-origin]: https://fetch.spec.whatwg.org/#concept-request-origin
 </section><!-- Algorithms::eligible -->
 <section>
 #### Parse <var>metadata</var>.
@@ -450,7 +450,7 @@ SHA256 hash value.
 User agents may allow users to modify the result of this algorithm via user
 preferences, bookmarklets, third-party additions to the user agent, and other
 such mechanisms. For example, redirects generated by an extension like
-[HTTPSEverywhere](https://www.eff.org/https-everywhere) could load and execute
+[HTTPS Everywhere](https://www.eff.org/https-everywhere) could load and execute
 correctly, even if the HTTPS version of a resource differs from the HTTP
 version.
 {:.note}
@@ -668,8 +668,8 @@ To help inform intermediate servers, those serving the resources SHOULD
 send along with the resource a [`Cache-Control`][cachecontrol] header
 with a value of [`no-transform`][notransform].
 
-[cachecontrol]: http://tools.ietf.org/html/rfc7234#section-5.2
-[notransform]: http://tools.ietf.org/html/rfc7234#section-5.2.1.6
+[cachecontrol]: https://tools.ietf.org/html/rfc7234#section-5.2
+[notransform]: https://tools.ietf.org/html/rfc7234#section-5.2.1.6
 
 </section><!-- /Implementation -->