And being behind authentication has by many been interpreted as “good enough” reason. Meaning that if you have “good reasons”, you can diverge from the recommendation. This safe heaven has lead a large number of applications to interpret the SHOULD NOT exactly as a should and not as a must. Namely behind authentication schemes that require humans at the steering wheel. The problem with the Accelerator is that its going places that used to be safe heaven from spiders. Put simply, GET requests should be idempotent and safe.
The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request in fact, some dynamic resources consider that a feature. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. These methods ought to be considered “safe”. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
Quoting from section 9.1.1 Safe Methods of the HTTP 1.1 RFC (2616): Update: If you use Ruby on Rails for your web-apps, here’s some code to just say no to Google Accelerator. Here’s an FAQ on prefetching for more information. This will keep Web Accelerator from clicking destructive links. If you have a web app, it might be worth returning a 403 when the HTTP_X_MOZ is set to “prefetch” header is sent. This wouldn’t be much of a problem on the public web since it’s pretty tough to be destructive on public web pages, but web apps, with their admin links here and there, can be considerably damaged. Once we figured this out we added some code to prevent Google from prefetching the pages and clicking the links, but it was quite disconcerting. We discovered this yesterday when a few people were reporting that their Backpack pages were “disappearing.” We were stumped until we dug a little deeper and discovered this Web Accelerator behavior. So, if you have a “Are you sure you want to delete this?” Javascript confirmation behind that “delete” link, Google ignores it and performs the action anyway. Here’s the problem: Google is essentially clicking every link on the page - including links like “delete this” or “cancel that.” And to make matters worse, Google ignores the Javascript confirmations. This gives the illusion of pages loading faster (since they’ve already been pre-loaded behind the scenes).
The accelerator scours a page and prefetches the content behind each link. Google’s web accelerator seems like a good thing for the public web, but it can wreak havok on web-apps and other things with admin-links built into the UI. Google Web Accelerator: Hey, not so fast - an alert for web app designers 225 comments
0 kommentar(er)
