> 3.2.1 Agility: the user agent will choose the strongest hash function in the list
Aside from the fact this contradicts the next section (Priority), it also would discourage browser vendors from adding better (slower) hashing functions as then they would be "forced" to utilise them.
Instead the standard should be: The "the fastest hash function which the browser finds secure." So if SHA-256 and SHA-512 were available, it would use SHA-256 until it was found insecure, then the browser would use SHA-512.
> Validation using unsupported hash functions always fails (see the “Does resource match metadataList” algorithm below). Authors are therefore encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.
No. Just no. If Chrome was the first to market with e.g. SHA-9999, I'd be unable to utilise that until literally every single browser on the market supported it (as it was fail by default).
Imagine if this standard existed in the IE6 days, today if you tried to use SHA-512 (which, let's assume, IE6 didn't support) the resources would fail to load every time (and you'd wind up having half a dozen different hashes just to hit something that was supported).
It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Fail by default isn't even the HTML way. Ignore by default is.
> It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Your proposal would make the hash attribute advisory. If I put a hash attribute on there, should I be able to count on it, and know that browsers won't load unless they can verify it? Or is it just advisory, and browsers may choose to ignore it, and I can't actually count on browsers only loading if hash matches?
Of course, I guess the fact that older browsers will always exist that ignore it (and that all browsers are essentially untrusted software, as far as the developer is concerned) may point to "you'd best consider it advisory only" anyway, I suppose.
Even without considering older browsers, the hash will be deliberately ignored by some clients for things like NoScript surrogates. Every tag and attribute is just advisory to the client; the client can always do what the user wants instead of what the server wants.
"If pipefail is enabled, the pipeline’s return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully"
reply