- From: <bugzilla@jessica.w3.org>
- Date: Tue, 30 Nov 2010 14:50:08 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11402
Johannes Barre <igel@igels.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |igel@igels.net
--- Comment #4 from Johannes Barre <igel@igels.net> 2010-11-30 14:50:07 UTC ---
Hi!
I reported this proposal in the first place, sorry for not replying so far.
> The real problem with this is that it will bitrot. If you update the file but
> don't update the hash in every single HTML file referring to it, then a bug
> will occur only for users who happen to have the old file in cache, which will
> be impossible to reproduce for other people. Even if the user clears cache,
> another site might be repopulating it, so the bug will recur for them but not
> the site admin. It's not obvious that the saved page loads are realistically
> worth the danger of this pitfall. (C.f. resource packages.)
Thats true. How about this:
1) The browser supports the hash attribute
1 1) The browser supports the requested hash algorithm:
1 1 1) The library is already cached (Hash matches) -> Use the cached file
1 1 2) The library is not cached -> Download the hash file and check the hash
1 1 2 1) The downloaded file matches the hash -> Use the downloaded file
1 1 2 2) The downloaded file doesn't match the hash -> Discard the downloaded
file, raise an JS exception
1 2) The browser doesn't support the requested hash algorithm -> Download and
use the specified file
2) The brower doesn't support the hash attribute -> Download and use the
specified file
1 1 2 2) Would make the error easier to track.
Regards, Johannes
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 30 November 2010 14:50:09 UTC