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


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

Re: Cherrypy - prevent browser "prefetch"?

Started byIsrael Brewster <israel@ravnalaska.net>
First post2014-12-02 06:59 -0900
Last post2014-12-03 10:06 -0900
Articles 3 — 2 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Cherrypy - prevent browser "prefetch"? Israel Brewster <israel@ravnalaska.net> - 2014-12-02 06:59 -0900
    Re: Cherrypy - prevent browser "prefetch"? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-12-03 19:17 +1300
      Re: Cherrypy - prevent browser "prefetch"? Israel Brewster <israel@ravnalaska.net> - 2014-12-03 10:06 -0900

#81803 — Re: Cherrypy - prevent browser "prefetch"?

FromIsrael Brewster <israel@ravnalaska.net>
Date2014-12-02 06:59 -0900
SubjectRe: Cherrypy - prevent browser "prefetch"?
Message-ID<mailman.16494.1417536013.18130.python-list@python.org>
> On Dec 2, 2014, at 4:33 AM, random832@fastmail.us wrote:
> 
> On Mon, Dec 1, 2014, at 15:28, Israel Brewster wrote:
>> 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?
> 
> Why is your logout form - or, your update caches form, etc - a GET
> instead of a POST?

Primary because they aren’t forms, they are links. And links are, by definition, GET’s. That said, as I mentioned in earlier replies, if using a form for a simple link is the Right Way to do things like this, then I can change it.

Thanks!

—————
Israel Brewster

> The key problem is that a GET request is assumed by
> browser designers to not have any harmful side effects.
> -- 
> https://mail.python.org/mailman/listinfo/python-list

[toc] | [next] | [standalone]


#81840

FromGregory Ewing <greg.ewing@canterbury.ac.nz>
Date2014-12-03 19:17 +1300
Message-ID<ce7o7pFgph2U1@mid.individual.net>
In reply to#81803
Israel Brewster wrote:
> Primary because they aren’t forms, they are links. And links are, by
> definition, GET’s. That said, as I mentioned in earlier replies, if using a
> form for a simple link is the Right Way to do things like this, then I can
> change it.

I'd look at it another way and say that an action with side
effects shouldn't appear as a simple link to the user. Links
are for requesting information; buttons are for triggering
actions.

-- 
Greg

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


#81869

FromIsrael Brewster <israel@ravnalaska.net>
Date2014-12-03 10:06 -0900
Message-ID<mailman.16538.1417633613.18130.python-list@python.org>
In reply to#81840

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

Ah, I see. That makes sense. Thanks.
-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
-----------------------------------------------


[toc] | [prev] | [standalone]


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


csiph-web