- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sat, 10 Aug 2013 19:17:14 -0700
- To: "'Chris Bojarski'" <chris@cbojar.net>, <public-html@w3.org>
± For example, François' major objection is that the browsers would be picking
± winners and losers with my proposed system {but popular librairies would also
± get an unfair boost under his proposal}
Yes, but in a very different fashion. If usage drives caching, this is totally fair as long as the web itself is fair, and we try very hard to make it so. If we used the other option (browser while lists), what if Google refuses to ship in Google Chrome a library Microsoft uses on its websites, or (more exactly) just do not want to dedicate someone's time working on that because there's no perf benefit for Google itself? Ditto for the reverse, and in all directions.
A caching-based solution is net-neutral because any library that gets used multiple times benefit from fast loading, not the one vetted by some authority (that actually do not want to play that role, browser vendors do not have time to spend reviewing popular libraries and keeping them up to date in their browsers).
± Conversely, winners and losers could still be chosen by popular home pages
± (ex. google.com) by loading those scripts in the background as soon as the
± browser opens that home page, but this would occur less transparently, and
± could be more easily perverted toward a particular commercial or otherwise
± non-neutral bias. (example: google.com could silently load all the scripts for
± Google and Gmail and GDrive, making their sites look much faster, while
± Yahoo! Mail would not get this benefit just because it's not the home page.)
This is already the case. They don't need my proposal for that. My proposal enables small websites to participate in this sharing without being dependent on the Google's CDN.
± Second, Nathaneal's suggestion is interesting, but includes its own
± challenges. By declaring any cryptographic encoding, one places an
± immediate expiration date on that standard. Today's uncrackable codes are
± tomorrow's ROT13's, so even with what is today a cryptographically strong
± algorithm, there would still be enormous security concerns.
Unlikely to become an issue. As mentioned, there are only around 1000 files having the same length+signature as an original file. The probability, even if someone could find them, that one of them is actually usable by an attacker is akin to zero.
± We'd also have to define "decompressed, encoding-normalized file
± contents." I'll start: tabs or spaces? 4 spaces or 2? CRLF, CR, or LF?
He clearly meant "the decompressed content once all transport-layer artifacts are being removed" (ie: the file the browser actually use). Nobody talks about transforming the source code before computing any hash, that would be insane.
± It would also involve whole other standards changes that would
± become complicated, and would require changes to HTTP servers, something
± system administrators would be loathe to do.
Well, if they don't want to optimize their site, it's their choice. They don’t have to.
I do think people will continue to use HTTP/1.1 for a while after HTTP/2.0 will be introduced, and it's totally ok. Not everybody needs every piece of performance increase.
± As to universal file names, I've
± seen: jquery.js, jquery.min.js, jquery-1.8.1.js jquery-1.8.1.min.js, and the
± ever popular script.js all used to refer to the same file. People don't like that
± kind of constriction; if they did, we could just use the file names already to
± accomplish this.
It's a performance tradeoff. Browsers can also use heuristics to reuse the same hash for similar file names, and we can even define which ones in the spec. Ignoring version numbers and ".min.js" would totally be an option. Developers could also maybe add a "name" attribute to their script tag to specify another name (supposed to be the 'standard' name) if they actually renamed it for some valid reason.
All in all, I still think "shared caching" is the best option we have, and if we take some time making is smart enough, there could be big wins.
Received on Sunday, 11 August 2013 02:17:49 UTC