Re: [integrity] The noncanonical-src attribute

On Fri, 13 Jun 2014 08:37:24 +0200, Simon Pieters <simonp@opera.com> wrote:

> http://w3c.github.io/webappsec/specs/subresourceintegrity/#the-noncanonical-src-attribute-todo
>
> I think the noncanonical-src feature is going to be insanely complicated  
> to get right. Please remove it. If authors want fallback, they can do so  
> in an imperative fashion, e.g.:
>
> <script src="https://example.com/script.js"
>          integrity="ni:///sha-256;jsdfhiuwergn...vaaetgoifq?ct=application/javascript"
>          onerror="var s = document.createElement('script');
>                   s.src = 'https://cdn.example.com/script.js';
>                   this.after(s);"></script>
>
> cheers

To elaborate, the <script> processing model is already insanely  
complicated as it is. Adding a fallback mechanism doesn't seem like it  
makes it any less complicated. The specification doesn't say what the  
processing model is, so it's a bit difficult to comment on it. Is it  
supposed to reset some state on the <script> element and start a new  
instance of the fetch algorithm? Is it supposed to hook into the existing  
fetch and make it act like it made a redirect? When exactly does this  
happen?

Why is the imperative fallback solution given above not sufficient?

P.S. Please cc me on replies since I'm not subscribed to the list.
-- 
Simon Pieters
Opera Software

Received on Monday, 16 June 2014 18:06:27 UTC