Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81774 > unrolled thread

Cherrypy - prevent browser "prefetch"?

Back to article view | Back to comp.lang.python

Contents

  Cherrypy - prevent browser "prefetch"? Israel Brewster <israel@ravnalaska.net> - 2014-12-01 11:28 -0900
    Re: Cherrypy - prevent browser "prefetch"? sohcahtoa82@gmail.com - 2014-12-01 12:41 -0800
    Re: Cherrypy - prevent browser "prefetch"? Nobody <nobody@nowhere.invalid> - 2014-12-02 21:05 +0000
      Re: Cherrypy - prevent browser "prefetch"? John Gordon <gordon@panix.com> - 2014-12-02 21:41 +0000
        Re: Cherrypy - prevent browser "prefetch"? Nobody <nobody@nowhere.invalid> - 2014-12-03 16:09 +0000

#81774 — Cherrypy - prevent browser "prefetch"?

[Multipart message — attachments visible in raw view] — view raw

I don't know if this is a cherrypy specific question (although it will be implemented in cherrypy for sure), or more of a general http protocol question, but when using cherrypy to serve a web app, is there anyway to prevent browser prefetch? I'm running to a problem, specifically from Safari on the Mac, where I start to type a URL, and Safari auto-fills the rest of a random URL matching what I started to type, and simultaneously sends a request for that URL to my server, occasionally causing unwanted effects.

For example, I have a URL on my Cherrypy app that updates some local caches. It is accessed at http://<server>/admin/updatecaches So if I start typing http://<server>/a, for example, safari may auto-fill the "dmin/updatecaches", and trigger a cache refresh on the server - even though I was just trying to get to the main admin page at /admin. Or, it might auto-fill "uth/logout" instead (http://<server>/auth/logout), and log me out of my session. While the former may be acceptable (after all, a cache update, even if not strictly needed, is at least non-harmfull), the latter could cause serious issues with usability. So how can cherrypy tell the difference between the "prefetch" and an actual request, and not respond to the prefetch?
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
-----------------------------------------------

[toc] | [next] | [standalone]

#81775

On Monday, December 1, 2014 12:29:04 PM UTC-8, Israel Brewster wrote:
> I don't know if this is a cherrypy specific question (although it will be implemented in cherrypy for sure), or more of a general http protocol question, but when using cherrypy to serve a web app, is there anyway to prevent browser prefetch? I'm running to a problem, specifically from Safari on the Mac, where I start to type a URL, and Safari auto-fills the rest of a random URL matching what I started to type, and simultaneously sends a request for that URL to my server, occasionally causing unwanted effects.
> 
> 
> For example, I have a URL on my Cherrypy app that updates some local caches. It is accessed at http://<server>/admin/updatecaches So if I start typing http://<server>/a, for example, safari may auto-fill the "dmin/updatecaches", and trigger a cache refresh on the server - even though I was just trying to get to the main admin page at /admin. Or, it might auto-fill "uth/logout" instead (http://<server>/auth/logout), and log me out of my session. While the former may be acceptable (after all, a cache update, even if not strictly needed, is at least non-harmfull), the latter could cause serious issues with usability. So how can cherrypy tell the difference between the "prefetch" and an actual request, and not respond to the prefetch?
> 
> 
> 
> 
> 
> -----------------------------------------------
> 
> Israel Brewster
> 
> Systems Analyst II
> 
> Ravn Alaska
> 
> 5245 Airport Industrial Rd
> 
> Fairbanks, AK 99709
> 
> (907) 450-7293
> 
> -----------------------------------------------

That sounds like a seriously misbehaving client to me.  Your browser should not be sending requests until the user actually chooses a URL to open.

The only thing I would suggest is to check the HTTP request headers (cherrypy.request.headers) of a genuine request versus one made by the automatic URL completion.  If there are different headers, such as maybe an "X-Prefetch: True" or something, you could check for that.

[toc] | [prev] | [next] | [standalone]

#81811

On Mon, 01 Dec 2014 11:28:42 -0900, Israel Brewster wrote:

> I'm running to a problem, specifically from
> Safari on the Mac, where I start to type a URL, and Safari auto-fills the
> rest of a random URL matching what I started to type, and simultaneously
> sends a request for that URL to my server, occasionally causing unwanted
> effects.

A GET request should not cause *any* effects. That's what PUT/POST are
for.

GET is for retrieval, not modification.

[toc] | [prev] | [next] | [standalone]

#81814

In <pan.2014.12.02.21.05.18.838000@nowhere.invalid> Nobody <nobody@nowhere.invalid> writes:

> On Mon, 01 Dec 2014 11:28:42 -0900, Israel Brewster wrote:

> > I'm running to a problem, specifically from
> > Safari on the Mac, where I start to type a URL, and Safari auto-fills the
> > rest of a random URL matching what I started to type, and simultaneously
> > sends a request for that URL to my server, occasionally causing unwanted
> > effects.

> A GET request should not cause *any* effects. That's what PUT/POST are
> for.

> GET is for retrieval, not modification.

GET shouldn't cause any business data modifications, but I thought it
was allowed for things like logging out of your session.

-- 
John Gordon         Imagine what it must be like for a real medical doctor to
gordon@panix.com    watch 'House', or a real serial killer to watch 'Dexter'.

[toc] | [prev] | [next] | [standalone]

#81865

On Tue, 02 Dec 2014 21:41:33 +0000, John Gordon wrote:

> GET shouldn't cause any business data modifications, but I thought it was
> allowed for things like logging out of your session.

GET isn't supposed to have observable side-effects. "Observable" excludes
things like logs and statistics, but getting logged out of your session is
definitely observable.

X-moz: prefetch, X-Purpose etc (note that these all have X- prefixes,
meaning that they're not in any standard) exist because web developers
seem to be uniquely bad at distinguishing between specified behaviour
and "seems to work".

But realistically, this horse is not only out of the barn but half way
around the world by now. So many sites misuse GET that there has to be
workarounds for it (to be honest, I'm surprised that they haven't made it
into a standard yet).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web