- From: Luke W Faraone <luke@faraone.cc>
- Date: Thu, 4 May 2017 15:04:06 -0700
- To: Alexander Forbes <axeforbes@uk.ibm.com>
- Cc: public-webappsec@w3.org
Received on Thursday, 4 May 2017 22:04:47 UTC
Alexander,
On 4 May 2017 at 13:13, Alexander Forbes <axeforbes@uk.ibm.com
<mailto:axeforbes@uk.ibm.com>> wrote:
> The spec supports multiple hashes so this should just work, iirc. Can
you test? I might be wrong.
My confusion here came from the spec stating ..."the user agent will
choose the strongest hash function in the list, and use that
metadata to validate the response". Basically: "more
collision-resistant hashes must always supersede weaker ones". This
ends up with some not-very-well-defined behaviour when you have
multiple hashes (e.g. having one of each sha512 and sha384 where
each represents a different version of the sub-resource). Only the
strongest should be checked in this case.
I think, in general, you should use some sort of cache-busting /
versioned URL, since the version of a JavaScript resource you are
loading will probably depend on versions of all the other resources.
Otherwise, you're approaching a world of non-determinism and bugs.
Could you provide an example use case that would benefit from the
freedom you describe?
Cheers,
Luke
Received on Thursday, 4 May 2017 22:04:47 UTC