HTTP header to detect a preload request by Google Chrome

Question

Google Chrome 17 introduced a new feature which preloads a webpage to improve rendering speed upon actually making the request (hitting enter in the omnibar).

Two questions: Is there a HTTP header to detect such a request on server side, and if one actually exists what is the proper response in order to prevent such preloading (to prevent unintended requests which might have unwanted effects)?

Does Google Chrome check the robots.txt before making preload requests? Is there a robots.txt setting which targets only this specific behaviour? (I supose/hope disallow already works).

Is there a meta tag to inform Google Chrome to never preload again on the current domain?

Exequatur

Answer 1

When Firefox pre-fetches content (at the behest of the referrer page’s markup), it sends the following header with the request: X-moz: prefetch

Safari does similarly, using: X-Purpose: preview. According to this ticket , Chrome does, too.

For pre-rendering, Chrome does not send any header whatsoever to the client. Instead, one must use the Page Visibility API, in JS

source, additional reading

Atween

From: code.google.com/intl/ro-RO/chrome/whitepapers/prerender.html Note: Chrome does not pass any distinguishing headers when prerendering occurs. Because the majority of prerenders convert into real pageviews, the Page Visibility API is the only way to correctly account for prerenders. When the page is shown to the user, no new requests are sent by Chrome, although you could create a script that uses the Page Visibility API to trigger a new request. – Exequatur

Emphasis on: "Chrome does not pass any distinguishing headers when prerendering occurs", which pretty much answer my question. Pre-fetching HTTP headers are not used at all (when requesting the body). – Exequatur

I think it needs to be made clear that pre-rendering and pre-fetching are not the same thing. Pre-fetching is on by default in major browsers and is always indicated by a special header (X-Purpose: preview in Chrome). Pre-rendering is an experimental Chrome feature which the developer must opt-in to. There is no header to detect pre-rendering because the developer knows if they've turned it on or not. – Stendhal

@Stendhal - Actually pre-rendering happens even when the developer doesn't opt in (e.g. when the user is typing in the url bar). It was the cause of a nasty bug for us. The only way to detect this AFAIK is via the page-visibility API, so there is no possibility to detect it server side. IMO they really should be setting a http header in this case (which they are not doing). – Teter

@Teter it's likely that the opt-in nature of prerendering has changed since I posted that. That said, it I believe prerendering only occurs via GET requests. As such, bugs resulting from Chrome prefetching API calls can be avoided by conforming to the HTTP standard and not performing actions as a result of GET requests. GET requests are for fetching data only. POST, PUT, and DELETE exist for other operations. Note that I'm not saying that your bug was in any way related to this. I'm simply mentioning it for he sake of people who may encounter this problem when building an API. – Stendhal

@krispy: Fetching data consumes resources and may result in error messages being generated on the server-side if the request was malformed (e.g. bad querystring). It's ludicrous to perform this automatically and have absolutely no way of indicating it. It's also a gross misuse of Chrome users' bandwidth. – Tacit

Answer 2

Chrome stopped sending X-Purpose header in 2011 and they stated that they won't fix it there: https://code.google.com/p/chromium/issues/detail?id=86175.

They re-introduced sending Purpose:prefetch headers with all nostate-prefetch requests back in 2018 as stated by the last comment on this issue. https://bugs.chromium.org/p/chromium/issues/detail?id=86175#c65

Watercool

Answer 3

Chrome is currently using a Sec-Purpose header with value: prefetch;prerender which has enabled us to detect such requests.

The problem in our case was that prefetch requests when the user was not logged in started the SSO process, which can't complete for a prefetch. So in this case, we return a 401 and wait for the 'real' request.

Prepay