Merge pull request #484 from fmarier/sri-issue440

SRI: fix broken links in the spec and upgrade them to HTTPS (fixes #440)

Author: devd

specs/subresourceintegrity/spec.markdown

@@ -54,8 +54,8 @@ 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
-[pinned public keys]: http://tools.ietf.org/html/draft-ietf-websec-key-pinning
+[HSTS]: https://tools.ietf.org/html/rfc6797
+[pinned public keys]: https://tools.ietf.org/html/rfc7469
 
 <section>
 ### Goals
@@ -127,11 +127,11 @@ The term <dfn>origin</dfn> is defined in the Origin specification.
 [[!RFC6454]]
 
 The terms <dfn>secure document</dfn> and
-<dfn>secure context</dfn> are defined in [section 2 of the Secure
+<dfn>secure context</dfn> are defined in section 2 of the [Secure
 Contexts][securecontext] specification. An example of a secure document is a
 document loaded over HTTPS. A counterexample is a document loaded over HTTP.
 
-[securecontext]: https://w3c.github.io/webappsec/specs/powerfulfeatures/#terms
+[securecontext]: http://www.w3.org/TR/powerful-features/
 [secure context]: #dfn-secure-context
 [secure document]: #dfn-secure-document
 
@@ -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
@@ -223,8 +223,8 @@ 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/CSP11/#source-list-syntax
-[openssl]: http://www.openssl.org/
+[csp2-section42]: http://www.w3.org/TR/CSP2/#source-list-syntax
+[openssl]: https://www.openssl.org/
 </div>
 
 [sha2]: #dfn-sha-2
@@ -341,8 +341,8 @@ only deliver integrity metadata on a [potentially secure origin][].  See
 
 {:.note}
 
-[uri-origin]: http://tools.ietf.org/html/rfc6454#section-4
-[Non-secure contexts remain non-secure]: #non-secure-contexts-remain-non-secure-1
+[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 -->
 
@@ -693,7 +693,7 @@ algorithms as defined in [section 5 of the Mixed
 Content][mixedcontent-algorithms]
 specification.
 
-[Securing the Web]: https://w3ctag.github.io/web-https/
+[Securing the Web]: http://www.w3.org/2001/tag/doc/web-https
 [mixedcontent-algorithms]: http://www.w3.org/TR/mixed-content/#algorithms
 </section><!-- /Security::Non-secure contexts remain non-secure -->