Hi!<div><br></div><div>I'm returning to this work now, and I see that folks have been quiet about this since I posted my plan.  Here's how I'm going to proceed:</div><div><br></div><div>Step 1: I will add beforeload to prefetch & icon rel types.  Expect a CL for this soon.</div>

<div>Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same.</div><div>Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp</div>

<div>Step 4: We land the Link header parser directly (bug 51940)</div><div>Step 5: Add beforeload events to the Link header?</div><div><br></div><div>Comments?<br><br><div class="gmail_quote">On 24 January 2011 18:10, Adam Barth <span dir="ltr"><<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2011/1/20 Gavin Peters (蓋文彼德斯) <<a href="mailto:gavinp@chromium.org">gavinp@chromium.org</a>>:<br>
<div class="im">> I also have thought about how we can go forward, I'd like folks<br>
> comments on this:<br>
><br>
> Step 1: Land bug 51941, a refactoring of the HTMLLinkPrefetch element<br>
> which pulls out loading for rel types prefetch, icon and dns-prefetch.<br>
<br>
</div>That sounds like a reasonable first step if we want to go forward with<br>
Steps 4 and 5.  Perhaps it would make sense to delay this work until<br>
we're ready to do Step 4?<br>
<div class="im"><br>
> Step 2: Add beforeload to at least prefetch & icon rel types, and hey,<br>
> why not dns-prefetch too!  Do this to fix bug 52577.<br>
<br>
</div>It seems reasonable to add beforeload events to prefetch.  Icon is<br>
probably worth doing too.  I'm less sure about dns-prefetch because<br>
that doesn't actually generate a "load" so to speak.  Maybe leave it<br>
off in the first iteration?<br>
<br>
My slight reservation here is that, from a privacy standpoint, there's<br>
no reasonable way to prevent a web site from leading information back<br>
to its server.  However, many privacy extensions take a "best effort"<br>
approach rather than an "airtight" approach.  In that sense,<br>
generating these events seems valuable because it improve what these<br>
folks can build.<br>
<div class="im"><br>
> Step 3: Add rel type subresource (same as rel type prefetch, only<br>
> higher priority for in-page resources) (need to create a bug for<br>
> this).<br>
<br>
</div>This seems valuable.  My understanding is that subresource is similar<br>
to prefetch, just with a different priority (i.e., "please prefetch<br>
this URL in time for it to be used by a subresource of this page").<br>
<div class="im"><br>
> Step 4: Add Link header, providing rel types subresource, prefetch &<br>
> dns-prefetch only (currently bug 51940).<br>
<br>
</div>This step also makes sense to me because these headers don't modify<br>
the semantics of the document.  Supporting them in headers means that<br>
web sites can optimize their performance using middleware boxes<br>
without hacking up their HTML.<br>
<div class="im"><br>
> Step 5: Add beforeload events to the Link header (as a followup after<br>
> bug 51940).<br>
<br>
</div>This seems somewhat odd to me, but I guess it makes sense.  There's<br>
some question about where to fire these events, but presumably firing<br>
them on the document itself would be fine.<br>
<br>
I'm willing to believe that my perspective might be biased because<br>
I've been talking to Gavin about these features for a while.  I<br>
certainly don't want us to move forward here if folks don't think this<br>
is a beneficial course of action.<br>
<font color="#888888"><br>
Adam<br>
</font></blockquote></div><br></div>