Folks,
I want to thank everyone who contributed to this thread on beforeload,
the link element, and the HTTP link header. The consensus was that it
was a mistake to add rel=prefetch without beforeload handlers, and
that it's a mistake to permit link headers to launch resource requests
before an extension or a page has had an opportunity to attach a
beforeload header. I think we can implement this feature and address
those concerns. I also had a chance last week to hear from a
developer who'd tried to make an SSL Everywhere extension for
Safari[1]. His experience was that more beforeload events would have
been helpful and he created Bug 52577. As well, Alexey drew our
attention to the Safari plugin Incognito (distinct from the Chrome
Incognito feature), which uses event capture on the beforeload event
to prevent cross-site loads to user-tracking sites (Google, Facebook,
ВКонтакте). Although, due to bug 52581, Safari actually launches
requests that capturers try to squash in event capture, which sort of
undermines everything Incognito is trying to do.
As well, there were also compelling arguments made in favour of
continuing experimentation with the Link header and prefetching. The
Link header has the potential to make the web faster; it enables
automated optimizers which can use link headers to provide server
hints, without having to change the HTML of a document being served.
I can imagine other uses too: a caching proxy can follow link
prefetch/subresource instructions, and sites with complex serving
infrastructure can have their front end servers insert link headers
while dynamic pages are being constructed in their backends. Without
continued experimentation, it's hard to know what difference this
feature can make.
I want to find a way forward then, to learn what performance can be.
So, I started this thread asking five questions, I'll repeat them with
where I think the right answers are now:
1. Should HTML Link rel=prefetch have beforeload events?
Yes.
2. How about rel=icon and rel=dns-prefetch ?
Yes for icon, not clear for dns-prefetch.
3. If the answer to (1) is yes, then should HTTP Link have events? Really?
Yes, at least for capture (which is what plugins use), otherwise
there's a way around blocking plugins.
4. Should HTML Link permit rel=subresource?
Sure.
5. If the answer to (4) is yes, should HTML Link rel=subresource have
beforeload events?
Yes, same reasons as all the other yesses.
I also have thought about how we can go forward, I'd like folks
comments on this:
Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element
which pulls out loading for rel types prefetch, icon and dns-prefetch.
Step 2: Add beforeload to at least prefetch icon rel types, and hey,
why not dns-prefetch too! Do this to fix bug 52577.
Step 3: Add rel type subresource (same as rel type prefetch, only
higher priority for in-page resources) (need to create a bug for
this).
Step 4: Add Link header, providing rel types subresource, prefetch
dns-prefetch only (currently bug 51940).
Step 5: Add beforeload events to the Link header (as a followup after
bug 51940).
Maciej asked a bit about Step 5: my thinking right now is that we only
care about capture (from the three stages: capture, target
bubbling). The two best use cases I've found for beforeload in
privacy enhancing situations were SSL Everywhere the Safari
Incognito extension. Both of them use the event capture interface, no
targets for beforeload events. So if we defer launching Link header
loads until epsilon after document start (only milliseconds away),
then we will have a target for the event capture interface; the events
need not have a target, since every use case we've considered uses the
capture interface only, and of course a target doesn't make sense if
the header is not to be in the DOM.
I hope that this addresses the concerns raised: we're respecting user
privacy, and separating our layers as much as possible; the only rel
types exposed in the Link header will be prefetch and subresource,
which are in a sense network layer since they speak only to cache
warming. Yet, they will still be capturable by extensions. This does
mean that we probably won't initially support Link header on non-HTML
documents as well, another question Alexey raised in the thread.
- Gavin
[1]
See http://www.nearinfinity.com/blogs/jeff_kunkle/lessons_learned_building_an_ht.html
for a good discussion from Jeff Kunkle about using beforeload.
[2] I just installed Incognito mode in a local Safari, and sniffed it.
I can confirm requests to blocked domains go straight through; with
cookies, everything. The only place you won't see them is in the
document, the DOM the Safari resource loading view. So Incognito
mode doesn't really stop tracking right now!
On 14 January 2011 20:23, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote:
Thanks for your message, Maciej!
On 14 January 2011 13:53, Maciej Stachowiak m...@apple.com wrote:
