Re: [webkit-dev] beforeload link (esp rel prefetch)
I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Steps 3-5 obviously depend on whether we want to proceed with adding support for the Link header field, which I'm not sure if it's got much support on webkit-dev. - WBR, Alexey Proskuryakov 22.02.2011, в 15:11, Gavin Peters (蓋文彼德斯) написал(а): Hi! 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: Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for this soon. Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/2/23 Alexey Proskuryakov a...@webkit.org: I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. Adam Steps 3-5 obviously depend on whether we want to proceed with adding support for the Link header field, which I'm not sure if it's got much support on webkit-dev. - WBR, Alexey Proskuryakov 22.02.2011, в 15:11, Gavin Peters (�w文彼德斯) написал(а): Hi! 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: Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for this soon. Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
23.02.2011, в 17:06, Adam Barth написал(а): I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. I've been looking at http://www.iana.org/assignments/link-relations/link-relations.xml and http://paramsr.us/tracker/issue?@sort=-activity@search_text=@dispname=Показать%20все@filter=@group=registry@columns=id,activity,title,creator,assignedto,status@pagesize=50@startwith=0status=-1,1,2,3registry=1, and don't see subresource there. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/2/23 Alexey Proskuryakov a...@webkit.org: 23.02.2011, в 17:06, Adam Barth написал(а): I think that adding beforeload to META-based prefetch and icon types makes a lot of sense. For subresource rel type, we may want to register it first, as mentioned by Julian. Looks like Gavin already registered it on 5 November 2010, so we're all set in that regard. I've been looking at http://www.iana.org/assignments/link-relations/link-relations.xml and http://paramsr.us/tracker/issue?@sort=-activity@search_text=@dispname=Показать%20все@filter=@group=registry@columns=id,activity,title,creator,assignedto,status@pagesize=50@startwith=0status=-1,1,2,3registry=1, and don't see subresource there. That's related to the following issue in the HTML working group: http://www.w3.org/html/wg/tracker/issues/27 The HTML5 spec currently refers to http://wiki.whatwg.org/wiki/RelExtensions, which is where Gavin registered the relation. In any case, we can register them in both places. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
Hi! 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: Step 1: I will add beforeload to prefetch icon rel types. Expect a CL for this soon. Step 2: I will add a new subresource rel type, which will have higher priority than prefetch, otherwise be the same. Step 3: We land bug 51941, which factors out the cache/LinkLoader.cpp from html/HTMLLinkElement.cpp Step 4: We land the Link header parser directly (bug 51940) Step 5: Add beforeload events to the Link header? Comments? On 24 January 2011 18:10, Adam Barth aba...@webkit.org wrote: 2011/1/20 Gavin Peters (蓋文彼德斯) gav...@chromium.org: 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. That sounds like a reasonable first step if we want to go forward with Steps 4 and 5. Perhaps it would make sense to delay this work until we're ready to do Step 4? Step 2: Add beforeload to at least prefetch icon rel types, and hey, why not dns-prefetch too! Do this to fix bug 52577. It seems reasonable to add beforeload events to prefetch. Icon is probably worth doing too. I'm less sure about dns-prefetch because that doesn't actually generate a load so to speak. Maybe leave it off in the first iteration? My slight reservation here is that, from a privacy standpoint, there's no reasonable way to prevent a web site from leading information back to its server. However, many privacy extensions take a best effort approach rather than an airtight approach. In that sense, generating these events seems valuable because it improve what these folks can build. 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). This seems valuable. My understanding is that subresource is similar to prefetch, just with a different priority (i.e., please prefetch this URL in time for it to be used by a subresource of this page). Step 4: Add Link header, providing rel types subresource, prefetch dns-prefetch only (currently bug 51940). This step also makes sense to me because these headers don't modify the semantics of the document. Supporting them in headers means that web sites can optimize their performance using middleware boxes without hacking up their HTML. Step 5: Add beforeload events to the Link header (as a followup after bug 51940). This seems somewhat odd to me, but I guess it makes sense. There's some question about where to fire these events, but presumably firing them on the document itself would be fine. I'm willing to believe that my perspective might be biased because I've been talking to Gavin about these features for a while. I certainly don't want us to move forward here if folks don't think this is a beneficial course of action. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/1/20 Gavin Peters (蓋文彼德斯) gav...@chromium.org: 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. That sounds like a reasonable first step if we want to go forward with Steps 4 and 5. Perhaps it would make sense to delay this work until we're ready to do Step 4? Step 2: Add beforeload to at least prefetch icon rel types, and hey, why not dns-prefetch too! Do this to fix bug 52577. It seems reasonable to add beforeload events to prefetch. Icon is probably worth doing too. I'm less sure about dns-prefetch because that doesn't actually generate a load so to speak. Maybe leave it off in the first iteration? My slight reservation here is that, from a privacy standpoint, there's no reasonable way to prevent a web site from leading information back to its server. However, many privacy extensions take a best effort approach rather than an airtight approach. In that sense, generating these events seems valuable because it improve what these folks can build. 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). This seems valuable. My understanding is that subresource is similar to prefetch, just with a different priority (i.e., please prefetch this URL in time for it to be used by a subresource of this page). Step 4: Add Link header, providing rel types subresource, prefetch dns-prefetch only (currently bug 51940). This step also makes sense to me because these headers don't modify the semantics of the document. Supporting them in headers means that web sites can optimize their performance using middleware boxes without hacking up their HTML. Step 5: Add beforeload events to the Link header (as a followup after bug 51940). This seems somewhat odd to me, but I guess it makes sense. There's some question about where to fire these events, but presumably firing them on the document itself would be fine. I'm willing to believe that my perspective might be biased because I've been talking to Gavin about these features for a while. I certainly don't want us to move forward here if folks don't think this is a beneficial course of action. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
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:
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Jan 20, 2011, at 5:52 PM, Gavin Peters (蓋文彼德斯) wrote: [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! Safari doesn’t have Incognito mode, so I’m not sure what you’re talking about here. If it’s Private Browsing you are referring to, then yes, that feature doesn’t even try to stop tracking. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/1/20 Darin Adler da...@apple.com: On Jan 20, 2011, at 5:52 PM, Gavin Peters (蓋文彼德斯) wrote: [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! Safari doesn't have Incognito mode, so I'm not sure what you're talking about here. If it's Private Browsing you are referring to, then yes, that feature doesn't even try to stop tracking. I think Gavin is referring to http://www.orbicule.com/incognito/ which does appear to be interested in stopping tracking. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
My apologies for the confusion: I did indeed mean the Safari extension incognito that Adam linked to, and not a mode. Alexey brought up this extension earlier in the thread as an example of a use of beforeload that should be permitted. - Gavin On Jan 20, 2011 8:55 PM, Darin Adler da...@apple.com wrote: On Jan 20, 2011, at 5:52 PM, Gavin Peters (蓋文彼德斯) wrote: [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! Safari doesn’t have Incognito mode, so I’m not sure what you’re talking about here. If it’s Private Browsing you are referring to, then yes, that feature doesn’t even try to stop tracking. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote: Thanks everyone for your replies on link headers and rel types. Mike Belshe from Chrome team put together a spec for these as part of Server Hints for SPDY. His server hint information is at: https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint , and link rel=subresource is at https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint/link-rel-subresource . The bottom line for rel=subresource is that we've found in early experiments that some page loads, especially of pages with dynamic content, are sped up by 15-20%; it's much more than mere milliseconds that we're talking about here. I'd like to do more experimentation with this, and to continue this we'd like to both have this rel type (with its prioritization) and the Link header (with its early arrival) I am skeptical of this testing and I would like to see the details. Anything you can put in a Link header in response headers, you can also put in a link element in the HTML response document. Even if the response is dynamically generated and therefore slow overall, it should be possible to emit a fixed portion with the prefetch hints. Therefore this strikes me as a workaround for poor Web application design. Link rel types significantly change the semantics of each link. rel=stylesheet changes the HTML page's presentation, and in bug 20018, Alexey raised some good points about how this affects saving web pages, and I think these rel types in an HTTP header are justifiably more controversial. But that having been said, the rel types prefetch, subresource, dns-prefetch are basically network level; they are instructions about cache seeding. No resultant document should view differently based on these headers; only faster. I agree that beforeload support could be more pervasive than it is today. The exclusion of prefetch, icon and dns-prefetch from beforeload events bears revisiting. But are these insurmountable? Currently the bug up for review, bug 51941 doesn't remove beforeload handling from anything that had it. The semantics of beforeload handlers for link headers wrt extensions bear some thought, but I suspect these can be solved: can we create another bug for adding this suppo It's not obvious how it could work, since a load triggered by a Link header has no associated element, and in fact starts before any elements exist. So there is nothing that can act as the event target. If you think it can be done, how about a proposal? Regards, Maciej - Gavin On 13 January 2011 12:48, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/1/14 Maciej Stachowiak m...@apple.com On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote: Thanks everyone for your replies on link headers and rel types. Mike Belshe from Chrome team put together a spec for these as part of Server Hints for SPDY. His server hint information is at: https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint, and link rel=subresource is at https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint/link-rel-subresource. The bottom line for rel=subresource is that we've found in early experiments that some page loads, especially of pages with dynamic content, are sped up by 15-20%; it's much more than mere milliseconds that we're talking about here. I'd like to do more experimentation with this, and to continue this we'd like to both have this rel type (with its prioritization) and the Link header (with its early arrival) I am skeptical of this testing and I would like to see the details. Anything you can put in a Link header in response headers, you can also put in a link element in the HTML response document. Even if the response is dynamically generated and therefore slow overall, it should be possible to emit a fixed portion with the prefetch hints. Therefore this strikes me as a workaround for poor Web application design. The statement above makes it sound like I said there was a 15+% speedup from this generically - that is certainly not the case! It is very dependent on content. The testing was done almost two years ago and not by me. You can find some of it on the chromium.org website; but because it is old data and not by me, I don't want to cite it as accurate. I simply want to say that there is some promise. We're actively ready to do experimentation with this inside of Chrome; but we need some leeway on testing it. It's a chicken and egg- we can't test it in real scenarios if we don't build it. Regarding poor web page design - You're right, webpages can always optimize around this. But, the web page optimization space is moving more and more to smart servers, and automated optimizers. Web document developers shouldn't need to know how to do these optimizations - it is something they are inherently not good at, and with every new site layout, they can easily regress. Enabling the HTTP level headers for this allows accelerators to monitor when these headers are appropriate and automatically insert them in an efficient manner. We are planning to test this case. Mike Link rel types significantly change the semantics of each link. rel=stylesheet changes the HTML page's presentation, and in bug 20018, Alexey raised some good points about how this affects saving web pages, and I think these rel types in an HTTP header are justifiably more controversial. But that having been said, the rel types prefetch, subresource, dns-prefetch are basically network level; they are instructions about cache seeding. No resultant document should view differently based on these headers; only faster. I agree that beforeload support could be more pervasive than it is today. The exclusion of prefetch, icon and dns-prefetch from beforeload events bears revisiting. But are these insurmountable? Currently the bug up for review, bug 51941 doesn't remove beforeload handling from anything that had it. The semantics of beforeload handlers for link headers wrt extensions bear some thought, but I suspect these can be solved: can we create another bug for adding this suppo It's not obvious how it could work, since a load triggered by a Link header has no associated element, and in fact starts before any elements exist. So there is nothing that can act as the event target. If you think it can be done, how about a proposal? Regards, Maciej - Gavin On 13 January 2011 12:48, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should
Re: [webkit-dev] beforeload link (esp rel prefetch)
Thanks for your message, Maciej! On 14 January 2011 13:53, Maciej Stachowiak m...@apple.com wrote: I agree that beforeload support could be more pervasive than it is today. The exclusion of prefetch, icon and dns-prefetch from beforeload events bears revisiting. But are these insurmountable? Currently the bug up for review, bug 51941 doesn't remove beforeload handling from anything that had it. The semantics of beforeload handlers for link headers wrt extensions bear some thought, but I suspect these can be solved: can we create another bug for adding this suppo It's not obvious how it could work, since a load triggered by a Link header has no associated element, and in fact starts before any elements exist. So there is nothing that can act as the event target. If you think it can be done, how about a proposal? Certainly immediately, the first thing that comes to mind is that we continue, as WebKit has for as long as it's had the rel types dns-prefetch, prefetch icon, to not issue beforeload events on these elements. That's the behaviour now, and it's been acceptable to date. Are you convinced it was a mistake to omit these rel types from beforeload now? That question seems independent of the Link header that's also been discussed in this thread, but if I'm wrong I'm totally open to hearing why it's a blocker now. If we decide to issue them, particularly on the header, I concur that it's tricky. I don't have a great proposal now for handling beforeload in link headers, and I'm not sure the ideas I do have are developed enough to really share, I suspect they're all both obvious and naive given the problem. But, counter balancing this problem, I'd like to continue to experiment with this feature and learn what benefits it has to offer. What's the way forward on that? - Gavin On 13 January 2011 12:48, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On 13.01.2011 07:42, Darin Fisher wrote: Firefox definitely supports rel=prefetch in HTTP Link headers. I believe it also supports other rel types, like stylesheet. The rel=subresource bit is something new. Yes, stylesheet is supported. For subresource, I *really* would like to see a proper spec. Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. Indeed. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
12.01.2011, в 22:42, Darin Fisher написал(а): Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd break base element. Historically, attempts to use HTTP metadata with HTML caused significant trouble - user agents don't even agree on Content-Type handling, and more complicated features like Vary pretty much don't work at all. Is there a reason to believe that fetching resources via Link will be anything more than a source of incompatibilities and security bugs? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On 13.01.2011 18:02, Alexey Proskuryakov wrote: 12.01.2011, в 22:42, Darin Fisher написал(а): Supporting the Link header enables web servers to injectlink tags without modifying the document, which can be useful, especially for intermediaries. I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Historically, attempts to use HTTP metadata with HTML caused significant trouble - user agents don't even agree on Content-Type handling, and more complicated features like Vary pretty much don't work at all. Is there a reason to believe that fetching resources via Link will be anything more than a source of incompatibilities and security bugs? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Thursday 13 January 2011 17:02:15 Alexey Proskuryakov wrote: As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. Could you elaborate on this a bit? I don't understand the potential breakage. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
13.01.2011, в 11:34, Robert Hogan написал(а): As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. Could you elaborate on this a bit? I don't understand the potential breakage. Privacy enhancing extensions such as this one block access to cross-domain subresources from sites known for pervasive user tracking. If some subresources avoid beforeload, they won't be blocked, and users will be tracked. I would expect that whatever an extension or a Web site wants to do with beforeload, it trusts that there is no bypass such as the Link header. Obviously, nothing will change in practice until sites actually start using the Link header. But widespread use of Link is something we should plan for if we're going to support it. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
2011/1/13 Darin Fisher da...@chromium.org: Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. That sounds like a great reason not to support this feature. Why would we want to make the web more unpredictable and harder to understand? From prefetching perspective this has little or no value. When we get the response header we are generally milliseconds away from parsing the real document text and requesting the linked resources properly. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
Thanks everyone for your replies on link headers and rel types. Mike Belshe from Chrome team put together a spec for these as part of Server Hints for SPDY. His server hint information is at: https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint, and link rel=subresource is at https://sites.google.com/a/chromium.org/dev/spdy/link-headers-and-server-hint/link-rel-subresource. The bottom line for rel=subresource is that we've found in early experiments that some page loads, especially of pages with dynamic content, are sped up by 15-20%; it's much more than mere milliseconds that we're talking about here. I'd like to do more experimentation with this, and to continue this we'd like to both have this rel type (with its prioritization) and the Link header (with its early arrival). Link rel types significantly change the semantics of each link. rel=stylesheet changes the HTML page's presentation, and in bug 20018, Alexey raised some good points about how this affects saving web pages, and I think these rel types in an HTTP header are justifiably more controversial. But that having been said, the rel types prefetch, subresource, dns-prefetch are basically network level; they are instructions about cache seeding. No resultant document should view differently based on these headers; only faster. I agree that beforeload support could be more pervasive than it is today. The exclusion of prefetch, icon and dns-prefetch from beforeload events bears revisiting. But are these insurmountable? Currently the bug up for review, bug 51941 doesn't remove beforeload handling from anything that had it. The semantics of beforeload handlers for link headers wrt extensions bear some thought, but I suspect these can be solved: can we create another bug for adding this support? - Gavin On 13 January 2011 12:48, Alexey Proskuryakov a...@webkit.org wrote: 13.01.2011, в 09:14, Julian Reschke написал(а): I'm wondering what the use cases are. To me, adding a way for metadata to change document behavior sounds like a misfeature - it adds significant complexity to the system, while taking away existing functionality. As a specific example discussed in this thread, we'd break some browser extensions like Incognito if resource loading could bypass onbeforeload. As another example, we'd breakbase element. Well, there are document types where you *can't* inline the metadata. Indeed, and I don't have anything against metadata as long as it doesn't directly modify actual data. For example, Last-Modified and Cache-Control are quite obvious example of what can be in HTTP headers. Despite the practical/historical difficulties that I mentioned with Content-Type, it's arguably a valid example of metadata, too. Subresource references on the other hand are a part of a document, not of its metadata. Am I just missing a reason why one would want to prefetch subresources for a JPEG image? We should distinguish between the act of declaring the link, and the moment where a potential fetch actually happens (it doesn't always happen, after all). I agree that stuffing things just to get a fetch to happen earlier maybe a premature optimization. Optimizing prefetch to start before actual document data arrives is highly controversial, but I believe that it's the primary reason why we're considering the Link header implementation. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] beforeload link (esp rel prefetch)
Folks, Right now in WebKit, beforeload events are not universally sent for link elements. In particular, link elements with the rel type icon, dns-prefetch and prefetch do not generate beforeload events. In a recent review of bug 51941, ap raised the question that perhaps they should be sent. It's a good question! As background, I'm right now refactoring the HTMLLinkElement to pull out the loader that handles the abovementioned three rel types. I'm doing this in preparation for adding Link header support, initially for these three rel types, as they are not so controversial as for instance putting rel=stylesheet in the HTTP headers. Then, there's another complication. After the refactoring described in bug 51941, I'd like to move on and implement the Link header, bug 51940. It's clear that beforeload won't make sense for the Link header, since we can't allow JS in HTTP, and we can't delay following the Link until we have HTML+CSS+JS (since that would defeat the purpose of the HTTP header providing quick dispatch). As well, I will likely add another rel type subresource to our handling together with the header, which describes something like a prefetch, but required for the current page. So now I see a few questions 1. Should HTML Link rel=prefetch have beforeload events? 2. How about rel=icon and rel=dns-prefetch ? 3. If the answer to (1) is yes, then should HTTP Link have events? Really? 4. Should HTML Link permit rel=subresource? 5. If the answer to (4) is yes, should HTML Link rel=subresource have beforeload events? what do people think? - Gavin https://bugs.webkit.org/show_bug.cgi?id=51941 https://bugs.webkit.org/show_bug.cgi?id=51940 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯) gav...@chromium.orgwrote: 1. Should HTML Link rel=prefetch have beforeload events? 2. How about rel=icon and rel=dns-prefetch ? I don't see why these wouldn't fire beforeload. They are resource requests like any others. I don't know enough about HTTP Link to comment on it. 1. If the answer to (1) is yes, then should HTTP Link have events? Really? 2. Should HTML Link permit rel=subresource? 3. If the answer to (4) is yes, should HTML Link rel=subresource have beforeload events? what do people think? - Gavin https://bugs.webkit.org/show_bug.cgi?id=51941 https://bugs.webkit.org/show_bug.cgi?id=51940 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
Chromium-specific note: link rel=icon is loaded externally to WebKit, which will likely complicate matters here. -Darin On Wed, Jan 12, 2011 at 8:52 AM, Ojan Vafai o...@chromium.org wrote: On Wed, Jan 12, 2011 at 8:05 AM, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote: 1. Should HTML Link rel=prefetch have beforeload events? 2. How about rel=icon and rel=dns-prefetch ? I don't see why these wouldn't fire beforeload. They are resource requests like any others. I don't know enough about HTTP Link to comment on it. 1. If the answer to (1) is yes, then should HTTP Link have events? Really? 2. Should HTML Link permit rel=subresource? 3. If the answer to (4) is yes, should HTML Link rel=subresource have beforeload events? what do people think? - Gavin https://bugs.webkit.org/show_bug.cgi?id=51941 https://bugs.webkit.org/show_bug.cgi?id=51940 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
On 12.01.2011 17:05, Gavin Peters (蓋文彼德斯) wrote: ... As background, I'm right now refactoring the HTMLLinkElement to pull out the loader that handles the abovementioned three rel types. I'm doing this in preparation for adding Link header support, initially for these three rel types, as they are not so controversial as for instance putting rel=stylesheet in the HTTP headers. ... Out of curiosity: what's controversial about that? ... header providing quick dispatch). As well, I will likely add another rel type subresource to our handling together with the header, which describes something like a prefetch, but required for the current page. ... ...if you mint new link relation names, please consider registering them (see RFC 5988 and http://paramsr.us/link-relation-types/). Best regards, Julian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
12.01.2011, в 10:26, Julian Reschke написал(а): they are not so controversial as for instance putting rel=stylesheet in the HTTP headers. ... Out of curiosity: what's controversial about that? Some of the discussion is written down in https://bugs.webkit.org/show_bug.cgi?id=20018. Issues around rel=prefetch (as discussed here) are a subset of those around rel=stylesheet. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
Do other browsers support these values in the HTTP Link header? Do Web sites use them? I think the idea of triggering subresource loads from HTTP headers instead of the HTML itself is problematic. We should support it only to the degree required for Web compatibility. Regards, Maciej On Jan 12, 2011, at 8:05 AM, Gavin Peters (蓋文彼德斯) wrote: Folks, Right now in WebKit, beforeload events are not universally sent for link elements. In particular, link elements with the rel type icon, dns-prefetch and prefetch do not generate beforeload events. In a recent review of bug 51941, ap raised the question that perhaps they should be sent. It's a good question! As background, I'm right now refactoring the HTMLLinkElement to pull out the loader that handles the abovementioned three rel types. I'm doing this in preparation for adding Link header support, initially for these three rel types, as they are not so controversial as for instance putting rel=stylesheet in the HTTP headers. Then, there's another complication. After the refactoring described in bug 51941, I'd like to move on and implement the Link header, bug 51940. It's clear that beforeload won't make sense for the Link header, since we can't allow JS in HTTP, and we can't delay following the Link until we have HTML+CSS+JS (since that would defeat the purpose of the HTTP header providing quick dispatch). As well, I will likely add another rel type subresource to our handling together with the header, which describes something like a prefetch, but required for the current page. So now I see a few questions Should HTML Link rel=prefetch have beforeload events? How about rel=icon and rel=dns-prefetch ? If the answer to (1) is yes, then should HTTP Link have events? Really? Should HTML Link permit rel=subresource? If the answer to (4) is yes, should HTML Link rel=subresource have beforeload events? what do people think? - Gavin https://bugs.webkit.org/show_bug.cgi?id=51941 https://bugs.webkit.org/show_bug.cgi?id=51940 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] beforeload link (esp rel prefetch)
Firefox definitely supports rel=prefetch in HTTP Link headers. I believe it also supports other rel types, like stylesheet. The rel=subresource bit is something new. Supporting the Link header enables web servers to inject link tags without modifying the document, which can be useful, especially for intermediaries. -Darin On Wed, Jan 12, 2011 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote: Do other browsers support these values in the HTTP Link header? Do Web sites use them? I think the idea of triggering subresource loads from HTTP headers instead of the HTML itself is problematic. We should support it only to the degree required for Web compatibility. Regards, Maciej On Jan 12, 2011, at 8:05 AM, Gavin Peters (蓋文彼德斯) wrote: Folks, Right now in WebKit, beforeload events are not universally sent for link elements. In particular, link elements with the rel type icon, dns-prefetch and prefetch do not generate beforeload events. In a recent review of bug 51941, ap raised the question that perhaps they should be sent. It's a good question! As background, I'm right now refactoring the HTMLLinkElement to pull out the loader that handles the abovementioned three rel types. I'm doing this in preparation for adding Link header support, initially for these three rel types, as they are not so controversial as for instance putting rel=stylesheet in the HTTP headers. Then, there's another complication. After the refactoring described in bug 51941, I'd like to move on and implement the Link header, bug 51940. It's clear that beforeload won't make sense for the Link header, since we can't allow JS in HTTP, and we can't delay following the Link until we have HTML+CSS+JS (since that would defeat the purpose of the HTTP header providing quick dispatch). As well, I will likely add another rel type subresource to our handling together with the header, which describes something like a prefetch, but required for the current page. So now I see a few questions 1. Should HTML Link rel=prefetch have beforeload events? 2. How about rel=icon and rel=dns-prefetch ? 3. If the answer to (1) is yes, then should HTTP Link have events? Really? 4. Should HTML Link permit rel=subresource? 5. If the answer to (4) is yes, should HTML Link rel=subresource have beforeload events? what do people think? - Gavin https://bugs.webkit.org/show_bug.cgi?id=51941 https://bugs.webkit.org/show_bug.cgi?id=51940 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
