[webkit-dev] Announcing the New England Browser Authors Meetup
Hi! Are you a webkit contributor or other browser author in New England? If so, read on, and consider coming to a half day unconference later this month on the web platform, to informally share your work, talk about the web platform, and meet other people working in browsers in the area! On 5/29, for a half day (starting just after lunch), authors of web browsers are encouraged to come to (LOCATION TBA, NEAR MIT, CAMBRIDGE) for an unconference of browser authors. We already have confirmed attendance from webkit contributors, mozilla committers, and chromium contributors who live and work in the New England area. If you do related work, consider coming; we'd like to hear what you are doing that's interesting. Don't prepare too long slide decks, but do prepare opinions about what browsers are getting right and getting wrong these days. Here's the attendee list, add yourself at the bottom: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Here's the session list, please sign up to give one, or ask for one here: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 When we start at 1pm, we'll go over the session list and assign slots. So come ready to vote on what you like, too! - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing the New England Browser Authors Meetup
Here is the CORRECT attendee list and agenda: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Apologies for getting it wrong in the announcement! On Fri, May 18, 2012 at 4:38 PM, Gavin Peters (蓋文彼德斯) gav...@webkit.orgwrote: Hi! Are you a webkit contributor or other browser author in New England? If so, read on, and consider coming to a half day unconference later this month on the web platform, to informally share your work, talk about the web platform, and meet other people working in browsers in the area! On 5/29, for a half day (starting just after lunch), authors of web browsers are encouraged to come to (LOCATION TBA, NEAR MIT, CAMBRIDGE) for an unconference of browser authors. We already have confirmed attendance from webkit contributors, mozilla committers, and chromium contributors who live and work in the New England area. If you do related work, consider coming; we'd like to hear what you are doing that's interesting. Don't prepare too long slide decks, but do prepare opinions about what browsers are getting right and getting wrong these days. Here's the attendee list, add yourself at the bottom: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Here's the session list, please sign up to give one, or ask for one here: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 When we start at 1pm, we'll go over the session list and assign slots. So come ready to vote on what you like, too! - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing the New England Browser Authors Meetup
And a third try. Here is the session list attendees: http://goo.gl/vwWMB - Gavin On Fri, May 18, 2012 at 4:46 PM, Gavin Peters (蓋文彼德斯) gav...@webkit.orgwrote: Here is the CORRECT attendee list and agenda: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Apologies for getting it wrong in the announcement! On Fri, May 18, 2012 at 4:38 PM, Gavin Peters (蓋文彼德斯) gav...@webkit.orgwrote: Hi! Are you a webkit contributor or other browser author in New England? If so, read on, and consider coming to a half day unconference later this month on the web platform, to informally share your work, talk about the web platform, and meet other people working in browsers in the area! On 5/29, for a half day (starting just after lunch), authors of web browsers are encouraged to come to (LOCATION TBA, NEAR MIT, CAMBRIDGE) for an unconference of browser authors. We already have confirmed attendance from webkit contributors, mozilla committers, and chromium contributors who live and work in the New England area. If you do related work, consider coming; we'd like to hear what you are doing that's interesting. Don't prepare too long slide decks, but do prepare opinions about what browsers are getting right and getting wrong these days. Here's the attendee list, add yourself at the bottom: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Here's the session list, please sign up to give one, or ask for one here: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 When we start at 1pm, we'll go over the session list and assign slots. So come ready to vote on what you like, too! - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Feature Announcement: Link Prerendering API
Link Prerendering is a feature of chromium to load entire web pages ahead of navigation. The feature has been enabled in our release branch for some time, and prerender links are found on many web sites, and are emitted by Google Web Search for first results sometimes. To learn more about prerendering, see https://developers.google.com/chrome/whitepapers/prerender I'm working on removing link rel=prerender ... loads from the main resource loading path, and instead giving the platform a prerendering interface. Right now, prerenders are a type of resource request. In the chromium port, our network stack catches the prerender loads, aborts them, and asynchronously launches a prerender. We've been having a really good experience with prerendering in chrome, and we're at the point where to help more sites adopt it, we need a better API; the load events are not quite right for prerenders, and prerenders are not quite network requests in many ways. Using a cachedresourceloader to fire off a load for a request that will not return data didn't quite make sense. Reviews are still ongoing, but the first few steps of this API are being worked on at https://bugs.webkit.org/show_bug.cgi?id=82478 , and in https://github.com/gavinp/git.webkit.org/pull/2 [1]. Please, follow along if you're interested. There's a corresponding chrome CL tracking this api at http://codereview.chromium.org/9875026/ , however that CL is not quite as up to date. I should update it in the next day or two, though. This first set of changes lets prerendering launchers signal that they want a prerender to be dropped, simply by removing the link element from the document. A separate signal is sent to the prerendering platform when the page is navigated away from. As well, prerenders are now sent to the platform fragment clean, and the code path doesn't include things like a cached resource loader, which for a prerender didn't really make sense. This API has been talked about at whatwg, at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035065.html, and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035394.html . - Gavin [1] I'm very happy with how a github pull request lets me easily show a change that has a lot of plumbing like this in layers. The interface for this aspect of it is great. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Feature Announcement: Link Prerendering API
I'd also like to ask specifically for guidance from reviewers, especially on ports other than Chromium, about how to handle the new files in WebCore that are part of the Link Prerendering API. Should I add them to other ports build files? The new files in WebCore that are only important to ports that have prerender on on are currently WebCore/loader/Prerenderer.*, WebCore/loader/PrerendererClient.*, WebCore/platform/PrerenderHandle.h. Those files basically all just have #if ENABLED(LINK_PRERENDER) surrounding the entire implementation. If you aren't using prerendering, they are empty files. I can see the arguments on this both ways. If I add them to the build files, then of course things will be easier for the lucky hacker adding prerender to another port in the future. We'll also benefit from having build files that are close to each other; every bit that we drift apart is more pain. Against adding to the other ports, I see that these are translation units that will slow down compiles; this is particularly true for anyone building with a smaller number of CPUs, where compile time and not link time dominates. Why subject hard working hackers to any slowdown for a feature they don't use? And besides, prerendering is a complex feature with much deeper implications than WebKit; whoever turns on prerendering in other implementations is not going to be put off by adding a few files to their project. WebKit-dev, wdyt? - Gavin On Thu, Apr 12, 2012 at 5:50 PM, Gavin Peters (蓋文彼德斯) gav...@webkit.orgwrote: Link Prerendering is a feature of chromium to load entire web pages ahead of navigation. The feature has been enabled in our release branch for some time, and prerender links are found on many web sites, and are emitted by Google Web Search for first results sometimes. To learn more about prerendering, see https://developers.google.com/chrome/whitepapers/prerender I'm working on removing link rel=prerender ... loads from the main resource loading path, and instead giving the platform a prerendering interface. Right now, prerenders are a type of resource request. In the chromium port, our network stack catches the prerender loads, aborts them, and asynchronously launches a prerender. We've been having a really good experience with prerendering in chrome, and we're at the point where to help more sites adopt it, we need a better API; the load events are not quite right for prerenders, and prerenders are not quite network requests in many ways. Using a cachedresourceloader to fire off a load for a request that will not return data didn't quite make sense. Reviews are still ongoing, but the first few steps of this API are being worked on at https://bugs.webkit.org/show_bug.cgi?id=82478 , and in https://github.com/gavinp/git.webkit.org/pull/2 [1]. Please, follow along if you're interested. There's a corresponding chrome CL tracking this api at http://codereview.chromium.org/9875026/ , however that CL is not quite as up to date. I should update it in the next day or two, though. This first set of changes lets prerendering launchers signal that they want a prerender to be dropped, simply by removing the link element from the document. A separate signal is sent to the prerendering platform when the page is navigated away from. As well, prerenders are now sent to the platform fragment clean, and the code path doesn't include things like a cached resource loader, which for a prerender didn't really make sense. This API has been talked about at whatwg, at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035065.html, and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-April/035394.html. - Gavin [1] I'm very happy with how a github pull request lets me easily show a change that has a lot of plumbing like this in layers. The interface for this aspect of it is great. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] img onabort=foo() ...
I'm reading through event handling on attributes which load media as I contemplate some changes for Link elements, and I came across a curiosity. The HTMLImageElement dutifully registers any onabort handler specified in the element, but I can't find any code path that would actually launch one. Certainly the ImageLoader can only send onbeforeload, onload, onerror. There also don't seem to be any LayoutTests with onabort set for an IMG. Am I missing a path, or is this now redundant? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Postmortum on webkit bug 71122
I just finished fixing http://crbug.com/75604 aka https://bugs.webkit.org/show_bug.cgi?id=71122 , and it was a long process, and pretty involved, and had a lot of cycles of change, wait for crash data, etc... So here's my postmortum: TL;DR No matter how sure you are you fixed a crashing bug, keep reading crash reports to be sure. TL;DR2 Practice release crash dump debugging regularly. Read dissassembled code and never trust symbols. TL;DR3 When in doubt, add more state to enhance crash dumps. TL;DR4 WebKit can save stacks in memory now. gav...@webkit.org can help you use this. WHAT WAS HAPPENING The ScriptRunner was crashing, and we were getting a lot of uploads. We couldn't reproduce it by going to the same URIs, but it was definitely happening a lot in the wild. It didn't seem like other WebKit ports were seeing this bug either, which was interesting. WHAT WE DID 1. The crash in ScriptRunner was happening in ScriptRunner::timerFired(), and it looked like a CachedScript in the list of runnable scripts was NULL. How did that happen? So I added a CRASH() to ScriptRunner::queueScriptForExecution(). This meant we would crash before setting up the Async event, and maybe get a more interesting stack on our crash dumps? https://bugs.webkit.org/show_bug.cgi?id=65563 2. From this, we learned a few things. Crash dumps told us we definitely had a broken ScriptElement, and every stack showed a network error was in progress. The CachedScript in the ScriptElement was bad, and we couldn't figure out why. So, we added a hidden state machine to ScriptElement to track down how it was being zeroed. Was it double notification, or was the load continuing after being stopped? Crash dumps would tell. https://bugs.webkit.org/show_bug.cgi?id=66939 3. It was double notification. Nobody could figure out how on earth double notification happened. Boy, I'd sure like to know the stack at the time of the first ScriptElement::notifyFinished() call... So we added a new stack saving facility to WebKit, and used it here to save a stack inside the ScriptElement on every call to ScriptElement::notifyFinished(). Mosquito, meet our sledgehammer. https://bugs.webkit.org/show_bug.cgi?id=69453 4. Oh, so the earlier stack was data received, but with a response code = 400? How interesting... Finally I could reproduce the bug, and introduce a fix. https://bugs.webkit.org/show_bug.cgi?id=71122 WHAT WORKED 1. Windows minidumps. In Chrome, our dev and canary channels have enabled a very useful option that gives you some heap. In walking the stack on Windows when crashing, any stack element interpretable as a pointer gets the 1024byte range [p-256,p+768] saved into the dump. This feature makes debugging from dev or canary windows minidumps superior to anything else. Learn how to use windb(a)g. 2. Progressive instrumentation. As usual, once I had a reproduction a fix was pretty easy. But, while I didn't have a reproduction, it was useful to add release assertions and watch crash dumps, to progressively zone in on this bug. 3. Adding new facilities to WebKit. You want stacks saved in memory on every platform? OK. https://bugs.webkit.org/show_bug.cgi?id=69018 WHAT DIDN'T WORK 1. Debuggers. Hackers who should have known better looked at release minidumps and symbols, and couldn't understand the variables. For a good example of this mistake from me, see http://code.google.com/p/chromium/issues/detail?id=75604#c21 . Want to see someone even smarter make the same mistake? http://code.google.com/p/chromium/issues/detail?id=75604#c43 The ScriptElement wasn't bogus, but the symbols data was. The symbols indicated ECX had this, when this was actually in EAX at the time, or [ESP]. Don't trust symbols in release builds; instead dissassemble the function, and figure out where the data is. The symbols probably said ECX because at the point of first dereference or maybe at call time, in that scope, this was probably in ECX. But in optimised code, that doesn't have much to do with anything anywhere else in the code. Read the dissassembly. 2. Reading code. I spent far, far too much time doing this. You know what, usually this works for me: I read code, consider the stack, have an AHA! moment, and fix my bug. Too bad this bug was beyond my cognitive horizon, and reading code was just a great way to waste time. 3. Not watching crashes. See comments 30 and 31 in the bug: http://code.google.com/p/chromium/issues/detail?id=75604#c30 . We should not have had confidence the problem was solved; since, hey, it wasn't. SPECIAL THANKS TO a...@webkit.org for encouraging me to instrument where it helps. cbent...@chromium.org for putting up with my yak shaving. ero...@chromium.org for showing me how to use windb(a)g. jap...@chromium.org for never giving up hope. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Postmortum on webkit bug 71122
[resend with nicer formatting] I just finished fixing http://crbug.com/75604 aka https://bugs.webkit.org/show_bug.cgi?id=71122 , and it was a long process, and pretty involved, and had a lot of cycles of change, wait for crash data, etc... So here's my postmortum: TL;DR No matter how sure you are you fixed a crashing bug, keep reading crash reports to be sure. TL;DR2 Practice release crash dump debugging regularly. Read dissassembled code and never trust symbols. TL;DR3 When in doubt, add more state to enhance crash dumps. TL;DR4 WebKit can save stacks in memory now. gav...@webkit.org can help you use this. WHAT WAS HAPPENING The ScriptRunner was crashing, and we were getting a lot of uploads. We couldn't reproduce it by going to the same URIs, but it was definitely happening a lot in the wild. It didn't seem like other WebKit ports were seeing this bug either, which was interesting. WHAT WE DID 1. The crash in ScriptRunner was happening in ScriptRunner::timerFired(), and it looked like a CachedScript in the list of runnable scripts was NULL. How did that happen? So I added a CRASH() to ScriptRunner::queueScriptForExecution(). This meant we would crash before setting up the Async event, and maybe get a more interesting stack on our crash dumps? https://bugs.webkit.org/show_bug.cgi?id=65563 2. From this, we learned a few things. Crash dumps told us we definitely had a broken ScriptElement, and every stack showed a network error was in progress. The CachedScript in the ScriptElement was bad, and we couldn't figure out why. So, we added a hidden state machine to ScriptElement to track down how it was being zeroed. Was it double notification, or was the load continuing after being stopped? Crash dumps would tell. https://bugs.webkit.org/show_bug.cgi?id=66939 3. It was double notification. Nobody could figure out how on earth double notification happened. Boy, I'd sure like to know the stack at the time of the first ScriptElement::notifyFinished() call... So we added a new stack saving facility to WebKit, and used it here to save a stack inside the ScriptElement on every call to ScriptElement::notifyFinished(). Mosquito, meet our sledgehammer. https://bugs.webkit.org/show_bug.cgi?id=69453 4. Oh, so the earlier stack was data received, but with a response code = 400? How interesting... Finally I could reproduce the bug, and introduce a fix. https://bugs.webkit.org/show_bug.cgi?id=71122 WHAT WORKED 1. Windows minidumps. In Chrome, our dev and canary channels have enabled a very useful option that gives you some heap. In walking the stack on Windows when crashing, any stack element interpretable as a pointer gets the 1024byte range [p-256,p+768] saved into the dump. This feature makes debugging from dev or canary windows minidumps superior to anything else. Learn how to use windb(a)g. 2. Progressive instrumentation. As usual, once I had a reproduction a fix was pretty easy. But, while I didn't have a reproduction, it was useful to add release assertions and watch crash dumps, to progressively zone in on this bug. 3. Adding new facilities to WebKit. You want stacks saved in memory on every platform? OK. https://bugs.webkit.org/show_bug.cgi?id=69018 WHAT DIDN'T WORK 1. Debuggers. Hackers who should have known better looked at release minidumps and symbols, and couldn't understand the variables. For a good example of this mistake from me, see http://code.google.com/p/chromium/issues/detail?id=75604#c21 . Want to see someone even smarter make the same mistake? http://code.google.com/p/chromium/issues/detail?id=75604#c43 The ScriptElement wasn't bogus, but the symbols data was. The symbols indicated ECX had this, when this was actually in EAX at the time, or [ESP]. Don't trust symbols in release builds; instead dissassemble the function, and figure out where the data is. The symbols probably said ECX because at the point of first dereference or maybe at call time, in that scope, this was probably in ECX. But in optimised code, that doesn't have much to do with anything anywhere else in the code. Read the dissassembly. 2. Reading code. I spent far, far too much time doing this. You know what, usually this works for me: I read code, consider the stack, have an AHA! moment, and fix my bug. Too bad this bug was beyond my cognitive horizon, and reading code was just a great way to waste time. 3. Not watching crashes. See comments 30 and 31 in the bug: http://code.google.com/p/chromium/issues/detail?id=75604#c30 . We should not have had confidence the problem was solved; since, hey, it wasn't. SPECIAL THANKS TO a...@webkit.org for encouraging me to instrument where it helps. cbent...@chromium.org for putting up with my yak shaving. ero...@chromium.org for showing me how to use windb(a)g. jap...@chromium.org for never giving up hope. On 2 November 2011 12:06, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote: I just finished fixing http://crbug.com/75604 aka
Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
Dan,
You're right. I'm adding #if PLATFORM(CHROMIUM) to this change shortly.
- Gavin
On 6 October 2011 13:07, Dan Bernstein m...@apple.com wrote:
On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819)
--- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev
96818)
+++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev
96819)@@ -113,6 +113,14 @@ ZeroedInStopLoadRequest,
ZeroedInNotifyFinished, } m_cachedScriptState;+
+// We grab a backtrace when we zero m_cachedScript, so that at later
crashes
+// we'll have a debuggable stack.
+enum {
+MaxBacktraceSize = 32
+};
+int m_backtraceSize;
+void* m_backtrace[MaxBacktraceSize]; };
This appears to increase the size of each ScriptElement instance by 256
bytes. I don’t know how bad a performance hit this is in real-world use, but
it is most certainly not something all vendors would like to include in
their releases. The way this change was made, however, it is almost
inevitable that a vendor would end up unknowingly shipping this performance
regression. This change was made on trunk, it is unconditionally compiled
in, and there is nothing obvious tracking undoing this change.
I think this is the wrong way to incorporate diagnostic code into WebKit.
___
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)
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)
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)
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)
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] HTML5 Web Links (RFC 5988)
On 11 November 2010 03:59, Julian Reschke julian.resc...@gmx.de wrote: Gavin wrote in https://lists.webkit.org/pipermail/webkit-dev/2010-November/015026.html: Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin That sounds great. Two thoughts: - please do not forget to take the anchor parameter into account -- either drop the header when it's present, or use it to determine the context of the link (see http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.5.2) - once you start supporting the title attribute you might want to consider sharing code with Content-Disposition for processing I18Nized titles (see related Chromium change feature request and change list at https://code.google.com/p/chromium/issues/detail?id=57830). Thanks Julian! I'll consider these points carefully. - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin On 9 November 2010 06:51, Alex Milowski a...@milowski.org wrote: Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2], has anyone plans to introduce such support into WebKit ? It seems like a straight forward behavior to adopt. At minimum, the CSS stylesheets specified in the Link: header would be inserted, in order, between the user agent stylesheets and the document's stylesheets. Are there any implementation issues that one could imagine with this RFC? There are some obvious interoperability questions until enough browsers sufficiently support this feature. [1] http://tools.ietf.org/html/rfc5988 [2] http://dev.w3.org/html5/spec/Overview.html#the-link-element -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ 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] X-Purpose, again!
On 8 October 2010 12:02, Dan Bernstein m...@apple.com wrote: On Oct 8, 2010, at 6:26 AM, Gavin Peters (蓋文彼德斯) wrote: In particular, Safari sends X-Purpose: preview headers on requests for resources and subresources motivated by the previw feature of Safari. That’s incorrect. The header is only present in the request for the main resource. Thanks for the correction. Can you tell me why that decision was made? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] X-Purpose, again!
Two weeks ago, I tried to land a patch in bug 46529 to add an X-Purpose: prefetch request header to link prefetch motivated requests from WebKit. I'd like to land this change, as I think it's an important part of making link prefetch work well. Link prefetching is part of HTML5. Link prefetching has been implemented by the Firefox browser for years. Chrome's prefetching experiments have shown that prefetching on the web today makes browsing faster. Currently, Firefox's longstanding prefetch implementation sends a request header X-Moz: prefetch on its prefetch requests. The proposed header name X-Purpose was chosen because it is what Safari already uses for its bitmap previews. In particular, Safari sends X-Purpose: preview headers on requests for resources and subresources motivated by the previw feature of Safari. I've also started a discussion in HTTPbis about changing this header to simply Purpose. That has not been decided yet, and I think we can go forward with X-Purpose, and rename the header as soon as there's good consensus in HTTPbis. Servers will use the X-Purpose header for a number of purposes. Servers under load may 500 prefetch requests, rather than server non-navigation motivated requests. Servers may 500 prefetch requests that would have retrieved non-cacheable content. Server operators who want accurate information on user-initiated navigations to their resources can use this header: when prefetch motivated requests arrive, they can respond with Cache-Control: must-revalidate which should force a 304 at user-initiated navigation[1]. Some server operators today opt-out of X-Moz prefetch motivated requests, and that may continue to happen. The X-Purpose header will not make requests any longer or different, except for prefetching motivated requests (which will be longer by about 20 bytes). Nor will this header make server response headers longer. Alexey in our earlier discussion was concerned that all server responses would have to have to be longer due to Vary: X-Purpose responses. This turns out to not be the case; a Vary response to prefetches doesn't make sense, since the entire purpose of the feature is to prime caches. To treat prefetch requests differently, instead 500 them as described above, or use the Cache-Control: must-revalidate trick above. Alexey asked how X-Purpose headers will affect corporate network monitoring software; he was particularly concerned that this header would make reports from network monitoring software less accurate. This turns out to not be the case; prefetches right now transit the network unmarked. The proposal is to mark prefetch motivated requests, which is more information than we had previously. Today you can't attribute any resource request to user navigation (since it might be prefetch motivated), but with this header, you have some requests (prefetch motivated requests that didn't use the cache-control trick) that you can't attribute user navigation to. So network monitoring has strictly more information. Eric Seidel, in the X-Purpose bug, asked why we'd tag prefetch motivated requests, when we don't, for instance, tag iframe or XMLHttpRequest motivated requests. I think the difference here is that there's effective conditional handling that servers can make; there are a wide variety of responses that servers can make to prefetches, discussed above, all of which result in well defined resources load semantics for user navigation. In the case of iframes, even display:none iframes or XMLHttpRequest, the result of this kind of differential handling is undefined: without putting very difficult to enforce requirements on pages themselves, it will stay undefined. Maciej last week suggested he'd get back to us and explain the motivations that the Safari team used for adding X-Purpose: preview, in case they were helpful here. He hasn't yet, but I'm sure I'd appreciate hearing about that! Have I missed anything? I think X-Purpose (or Purpose, or X-Moz...), is an important part of a link prefetching implementation. It's requested by server operators, it has been used in the X-Moz form for years, and it helps servers gather statistics properly handle load. It also makes network monitoring software more accurate. And all this, without significantly lengthening requests. I hope I don't sound thick headed here, but I don't see a downside. Can we go ahead and land this change? Is there something missing from the above? If something is missing, please reply and explain what it is and how you think it might be addressed. Thanks! - Gavin [1] Unfortunately, such servers are losing some of the benefit of prefetching since there's at least one critical-path RTT, and possibly two (if no warm TCP connection is available) for these kinds of validated navigations. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose on prefetching requests
Noone has commented on this thread in some time; is this less controversial now? On 24 September 2010 21:27, Alexey Proskuryakov a...@webkit.org wrote: Eric has made another good point in Bugzilla - we don't explain the purpose in lots of other cases, from loading into a display:none frame to XMLHttpRequest. Why should Prefetch be all the different? Those requests are still part of loading a page as requested by the user, and failing them or returning a 500 will result in undefined behaviour; the result of failing part of a page is unpredictable. In the case of prefetches, we're in a very different space. The prefetch load has no effects on the DOM of the current resource (unlike display:none elements). There is no javascript event, or history impact, etc... (unlike XMLHttpRequest). A subsequent navigation will occur correctly whether there was no prefetch, a prefetch that failed, a prefetch that requires revalidation, and a prefetch that can be used without revalidation. So that, in my mind, leaves the balance in favour of emitting the header, as Mozilla Safari currently do in similar situations. Thoughts? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose on prefetching requests
On 28 September 2010 11:58, Alexey Proskuryakov a...@webkit.org wrote: 28.09.2010, в 07:58, Gavin Peters (蓋文彼德斯) написал(а): Noone has commented on this thread in some time; is this less controversial now? I've presented some concerns about the effect of this on enterprise network monitors. It it also not really clear what the benefits of the proposed approach are. It's beginning to sound like this header doesn't even help statistics much, and the only practical use is refusing to serve a request under high load. But I suspect that there is not much difference between returning a 5xx response and serving a cached pseudo-static version of a resource. It should be much easier to implement the latter (which lots of servers obviously already do) than to change behavior based on current load. The header allow high load opt out, as you suggested. It also allows general opt-out of prefetching by servers. Additionally, it is the only way you'd gather statistics about who has prefetch links targeting you (from Referer when provided with prefetch). Without this header, there is no way at all for servers to gather statistics on user initiated navigations vs prefetches; with it, you can use cache-control to make this determination. I see those as benefits, and I think they're nonzero. On the cost side, I see a small increase in the size of prefetch requests (and that cost is born only by this type of request, not by any other kind) and the hassle you mentioned in network monitoring. We can probably agree that the cost of the extra request headers is minimal, so hopefully that's not a very high hurdle to overcome. The remaining question then is: how much weight should be given to the difficulties of network monitoring software authors? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose on prefetching requests
Forgive the second follow up, I want to just clarify something. See below. On 28 September 2010 11:58, Alexey Proskuryakov a...@webkit.org wrote: I've presented some concerns about the effect of this on enterprise network monitors. I've thought about this some more, and and I think I don't get this actually. Could you clarify for me? What effect does this header have on network monitoring software, distinct from prefetching itself? If we lack the request header, then network monitoring software can't attribute browsing action to users at all; any request might be a prefetch. In the presence of this header, the network monitoring software can determine which requests began as prefetches, and, depending on the nature of the response, it may or may not be able to determine if a later user initiated navigation to that resource occured. Doesn't this header actually help network monitoring software? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose on prefetching requests
On 28 September 2010 20:25, Alexey Proskuryakov a...@webkit.org wrote: 28.09.2010, в 17:07, Gavin Peters (蓋文彼德斯) написал(а): If you're questioning if prefetch can make page loads faster, I can say that on the web today it does. Thank you for the information. Does the performance increase come at the cost of correctness? I.e., are these sites requiring revalidation on each load? That's a great question, and I don't have data on it in aggregate. The only examples I know of for pages varying behaviour based on the X-Moz header are sites that deny prefetches. I hope that revalidation will end up being somewhat rare: adding a RTT to the root document of a page of course slows down first paint, onload, etc.. by pretty much exactly one RTT. If correctness requires it, so be it, but if a resource would have been cacheable on a user-initiated load, I hope site operators would allow it to be cacheable for prefetchers over the same period. Of course, this is the default behaviour now, and it's the one that webkit enforces. The samples of prefetching on the web today are mostly cross site. Can you provide any examples? Yes. Google Web Search provides a prefetch link to the first search result in many cases. These links are (almost?) always cross site. - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] X-Purpose on prefetching requests
When the prefetch feature was originally added to WebKit, the first patch (bug 3652), it had a header X-Moz, for backwards compatibility with Firefox. Currently, when Firefox follows link prefetch requests, it adds a header X-Moz: prefetch to the request. However, before 3652 was landed, we removed this. The X-Moz header is pretty ugly, it has a very bad name. I felt a bit unsatisfied about this, so today I circled back and landed a patch to cause WebKit, when following prefetches, to send an X-Purpose: prefetch header, which is modelled closely on the X-Purpose: preview header that is sent by Safari when it does its preview generating loads (for those pictures of websites you see on the new tab screen). That patch is in bug 46529. I've also started a discussion in the HTTPbis working group about the three incompatible methods of notification that exist (X-Moz, X-Purpose, and do nothing), to see if a new header Purpose makes sense. The X-Purpose patch was controversial though; so Alexey Proskuryakov suggested we start a discussion in the mailing list. Right now, as I see it (and please chime in with what I'm missing), points in favour of sending X-Purpose are: - Conformity. Existing browsers that do prefetching/previewing notify servers, WebKit browsers should follow this. - Differentiation. Allows some kinds of differential treatment. A heavily loaded server may not want to serve prefetches, and 500 them. Some servers today 404 all X-Moz requests; while I think that's a shame, it is good to let people opt out of a feature. - Statistics. Server authors may wish to distinguish the origins of their traffic; although of course this is tricky, since prefetch loads are not always viewed and not always ignored. (send Cache-Control: must-revalidate) to prefetch requests, and you'll accurately know about uses, although at some cost in latency for your users. - Monitoring. Perhaps your web monitoring software or network operations department would like to know the difference between user navigation, and browser-initiated navigation. However, against X-Purpose, we have: - Acceptance. We want prefetching to succeed, and this header will promote opt-out. Besides, opt-out after getting the request is slow anyway. - Cost. Why make requests longer than they need to be? - Dangerous. If people vary content based on this header, they could cause all sorts of caching troubles (for instance a proxy might cache a 404 from a server that's differentiating traffic). What do people think? From I think we should follow existing practice, and send the header. I don't think the header cost is very big, and I am not sure that caching 404s is defensible anyway. Lots of headers shouldn't be used to mutate content; this is not new. Thoughts? - Gavin For the original landing of prefetching, see: https://bugs.webkit.org/show_bug.cgi?id=3652 For this new bug, see: https://bugs.webkit.org/show_bug.cgi?id=46529 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] X-Purpose on prefetching requests
On 24 September 2010 21:27, Alexey Proskuryakov a...@webkit.org wrote: 24.09.2010, в 17:31, Gavin Peters (蓋文彼德斯) написал(а): - Cost. Why make requests longer than they need to be? If used correctly, this will make responses longer, too (due to Vary: X-Purpose). Due to the nature of Vary, it will need to be sent with every response for the resource, not just those that are in response to prefetch requests. I think I might be missing this point. For the purposes of prefetching, I think that once you send out a Vary: X-Purpose header, you've basically opted out of permitting prefetching. Why wouldn't such a site send out a non-cacheable failure to prefetching requests? A 500 or 404 would likely not cause a cache discard, and so an eventual user navigation will just cause cache validation; but that's OK: the prefetch wouldn't have resulted in network activity if the cache was fresh anyway. Is there another case I'm forgetting or not understanding? I can see how this might be different in the X-Purpose: preview case, but that cat's out of the bag. Eric has made another good point in Bugzilla - we don't explain the purpose in lots of other cases, from loading into a display:none frame to XMLHttpRequest. Why should Prefetch be all the different? That I don't have a good answer to; we don't. For prefetching browsers traditionally have, but for these cases they haven't. Prefetching is not all that different than a display:none frame I suppose. - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
No, no other browsers support it. There's a similar feature in Mozilla, the LINK rel=prefetch item, but to my knowledge, Mozilla does not support the Link header. On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) gav...@chromium.orgwrote: I'm starting hacking at adding support for the Link: http header. This is described in RFC 2068, although not RFC 2616. As well, there's a current internet draft describing it: http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . This header is being discussed in the IETF HTTP WG mailing list. Since it was in HTTP 1.1 as first published, it is reserved, and legal to use today for this purpose. Is this supported in any other browsers? Do websites make use of it? I'm not saying you should necessarily stop if the answers are no, but it's good to know the lay of the land. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Link http header support
David's right, Mozilla has it. https://developer.mozilla.org/en/link_prefetching_faq They support it for rel=next and rel=prefetch. Unfortunate, as I also think rel=subresource matters, and should be distinguished from prefetch for prioritization. - Gavin On Thu, Jun 3, 2010 at 4:15 PM, David Hyatt hy...@apple.com wrote: Really? I thought they did, at least for stylesheets. dave On Jun 3, 2010, at 8:14 AM, Gavin Peters (蓋文彼德斯) wrote: No, no other browsers support it. There's a similar feature in Mozilla, the LINK rel=prefetch item, but to my knowledge, Mozilla does not support the Link header. On Wed, Jun 2, 2010 at 8:41 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) gav...@chromium.org wrote: I'm starting hacking at adding support for the Link: http header. This is described in RFC 2068, although not RFC 2616. As well, there's a current internet draft describing it: http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . This header is being discussed in the IETF HTTP WG mailing list. Since it was in HTTP 1.1 as first published, it is reserved, and legal to use today for this purpose. Is this supported in any other browsers? Do websites make use of it? I'm not saying you should necessarily stop if the answers are no, but it's good to know the lay of the land. PK ___ 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] Proposal: Link http header support
Hi, I'm starting hacking at adding support for the Link: http header. This is described in RFC 2068, although not RFC 2616. As well, there's a current internet draft describing it: http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html . This header is being discussed in the IETF HTTP WG mailing list. Since it was in HTTP 1.1 as first published, it is reserved, and legal to use today for this purpose. The HTTP Link header should be treated nearly identically to an HTML Link element. This means that guidance for stylesheet, subresource stylesheet loading can be provided to a browser before any parse of HTML has been started. Possibly a win. Right now, Leon Clarke has a patch he's landing for the link rel=prefetch case in HTML, see https://bugs.webkit.org/show_bug.cgi?id=3652 . I'd like to code this up for headers as well. At first, I'd like to take a relatively simpleminded approach. I don't want to carry forward DOM implications of the HTTP header (i.e. i'll ignore an onload attribute), and I don't think I'll share much code with HTMLLinkElement.cpp. However, I'm open to feedback on this. I intend to catch a few simple rel cases (subresource, prefetch stylesheet) and launch appropriately prioritized resource requests. Any thoughts? - Gavin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
