- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 14 Oct 2009 15:45:41 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 Summary: prefetching: allow site to deny Product: HTML WG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: HTML5 spec proposals AssignedTo: dave.null@w3.org ReportedBy: Nick_Levinson@yahoo.com QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, mike@w3.org, public-html@w3.org Prefetching should be deniable, because it demands bandwidth, especially when dynamism makes accurately predicting what will be fetched unlikely. Most site owners will happily keep speeds up but some will want to control costs. Prefetching is good for visitors. If the specific predictions are highly accurate, and I imagine they would be on most sites, the bandwidth penalty is small and probably easily overcome by visitor satisfaction leading to stiktion, repeat visits, and a positive reputation for new visitors. But the cost objection is right regarding sites where the arrangement of pages is less obvious, and especially where a page is dynamic, leading to more prefetch demands that may generate error pages or hits that don't correlate with visitors' actual interests, so that visitors don't even glance at much that has been prefetched at the site owner's expense. For example, if a visitor is reading a series of pages that have "Next Page ->" links and the link is to a script that generates a page based on how long the visitor stayed at the current page, the prefetch would probably be erroneous. A link supporting prefetch being absent is not a bar to prefetching (see section 4.3.1), so the absence of the link is not sufficient protection. Two solutions are proposed, one easier and the other more specific, and not mutually exclusive. The easier solution would be a local file that could deny all prefetching sitewide. The file should be modeled on robots.txt, should be named use.txt, should be commentable like robots.txt, and should have one noncomment line strippable of any leading whitespace: prefetch no The UA, before prefetching anything at a domain, should be required to check for that file and its command. The reason for naming the file use.txt rather than prefetch.txt is to support growth of the file for other purposes that may be offered or prescribed in the future. If it is desired to add utility to use.txt before any other terms are semanticized or reserved, private use could be supported for any term beginning with "x-" or "data-" (your choice of which to adopt). The more specific solution would be a per-page or per-element denial of prefetching by a link, a, or area element. An attribute could be rel="noprefetch" (i.e., don't prefetch the URL in the href), rev="noprefetch" (i.e., don't prefetch the page bearing the link element), or either noprefetch="true" (false being trivial) or prefetch="false" (true being trivial). I'll likely add the rel to RelExtensions soon but the other solutions don't go there. If what is to be prefetched is from another website, one website should not be permitted to bar prefetching from another website. The website from which the resource is to be prefetched would have the option of denying prefetching and the UA would have to recognize that bar. For example, if a user visits example.com and the UA, whether parsing example.com or not, sees fit to prefetch from example.org, only example.org could bar the prefetching from example.org. If a UA wants to prefetch two items for sequential use and if the first is denied the second would not be prefetched before the first is fetched, but if the first is allowed and the second is denied the UA would prefetch the first and fetch but not prefetch the second. If a UA wants to prefetch two items for joint or parallel purposing and one is denied and the other is allowed, I don't know whether there should be an HTML5-prescribed default whereby just one or neither is prefetched or the UA should decide whether to prefetch just one or neither. Thank you. -- Nick -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 14 October 2009 15:45:45 UTC