Re: Cherrypy - prevent browser prefetch?
On Tue, 02 Dec 2014 21:41:33 +, 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). -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
Ah, I see. That makes sense. Thanks. --- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- BEGIN:VCARD VERSION:3.0 N:Brewster;Israel;;; FN:Israel Brewster ORG:Frontier Flying Service;MIS TITLE:PC Support Tech II EMAIL;type=INTERNET;type=WORK;type=pref:isr...@frontierflying.com TEL;type=WORK;type=pref:907-450-7293 item1.ADR;type=WORK;type=pref:;;5245 Airport Industrial Wy;Fairbanks;AK;99701; item1.X-ABADR:us CATEGORIES:General X-ABUID:36305438-95EA-4410-91AB-45D16CABCDDC\:ABPerson END:VCARD On Dec 2, 2014, at 9:17 PM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: 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 -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
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? 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
Re: Cherrypy - prevent browser prefetch?
On Dec 2, 2014, at 4:33 AM, random...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
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 gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On Tue, Dec 2, 2014, at 10:59, 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. As I understand it, the usual way to do this these days is to have a link which, A) when navigated to, provides a simple standalone form confirming the action with a button and B) when clicked on with a browser with javascript enabled, automatically submits a hidden form, or an AJAX/JSON request or something, to accomplish the same task skipping the standalone page entirely. This will also have the effect of keeping these entries out of your browser history. Any action which has harmful or annoying side effects should definitely not be a GET. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
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 -- https://mail.python.org/mailman/listinfo/python-list
Cherrypy - prevent browser prefetch?
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 BrewsterSystems Analyst IIRavn Alaska5245 Airport Industrial RdFairbanks, AK 99709(907) 450-7293---BEGIN:VCARD VERSION:3.0 N:Brewster;Israel;;; FN:Israel Brewster ORG:Frontier Flying Service;MIS TITLE:PC Support Tech II EMAIL;type=INTERNET;type=WORK;type=pref:isr...@frontierflying.com TEL;type=WORK;type=pref:907-450-7293 item1.ADR;type=WORK;type=pref:;;5245 Airport Industrial Wy;Fairbanks;AK;99701; item1.X-ABADR:us CATEGORIES:General X-ABUID:36305438-95EA-4410-91AB-45D16CABCDDC\:ABPerson END:VCARD -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On 2014-12-01 11:28, 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. This SO post[1] suggests that Firefox sets/sends a X-moz: prefetch header, while Safari and Chrome use the X-Purpose: preview header. You could create a decorator that sniffs those headers and reacts accordingly. Though be aware that, based on my reading, Safari only sends that X-Purpose header for the base page, not any referenced assets (JS, CSS, images, etc). Also, while I can't find any documentation on how Safari/Chrome(ium) handle it, if your logout/ page sends an HTTP/302 redirect to a final landing page, Safari/Chrome(ium) may be smart enough to not suggest (and thus not prefetch) the bounce page, only the landing page. I haven't investigated recently, but I remember Django's ability to trigger a log-out merely via a GET was something that irked me. I don't have a recent version of Safari (my only Apple machine is a PPC iBook laptop running 10.4 which no longer receives any updates) so I can't verify that this header is actually being sent in the case you describe, but it would be where I'd start hunting. All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) -tkc [1] http://stackoverflow.com/questions/9852257/http-header-to-detect-a-preload-request-by-google-chrome -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
Tim Chase wrote: I haven't investigated recently, but I remember Django's ability to trigger a log-out merely via a GET was something that irked me. All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) ACK. However, isn't log-out an idempotent action? -- Christoph M. Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On 12/1/14 4:26 PM, Tim Chase wrote: On 2014-12-01 11:28, 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. All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) This is the key point: your web application shouldn't be doing these kinds of actions in response to a GET request. Make them POST requests, and Safari won't give you any trouble. Trying to stop Safari from making the GET requests might work for Safari, but then you will find another browser, or a proxy server, or an edge-caching accelerator, etc, that makes the GET requests when you don't want them. The way to indicate to a browser that it shouldn't pre-fetch a URL is to make it a POST request. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On 2014-12-01 22:44, Christoph M. Becker wrote: Tim Chase wrote: haven't investigated recently, but I remember Django's ability to trigger a log-out merely via a GET was something that irked me. All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) ACK. However, isn't log-out an idempotent action? A minor note here...the OP talked about CherryPy and I've been in Django-land too long that I started talking Django. I'd have to pick open the scabs of my CherryPy experience to answer about CP. But yes, it appears that Django's contrib.auth module still allows for performing a logout/ on a GET (something I remember encountering/researching several years ago) rather than limiting it to a POST. As best I can tell, it doesn't even check the refer(r)er, so this charmingly means that I can put a tag like img src=http://yoursite.example.com/logout/; on *my* site, and it will log you out from yoursite.example.com despite. Not even a CSRF-token check because it's not a POST. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On 2014-12-01 16:50, Ned Batchelder wrote: On 12/1/14 4:26 PM, Tim Chase wrote: All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) This is the key point: your web application shouldn't be doing these kinds of actions in response to a GET request. Make them POST requests, and Safari won't give you any trouble. Though to be fair, based on the reading I did, Safari also pulls in the various JS and executes it too, meaning that merely (pre)viewing the page triggers any Google Analytics (or other analytics) code you have on that page, sending page views with a high bounce rate (looks like you only hit one page and never browsed elsewhere on the site). Additionally, if the target GET URL involves high processing load on the server, it might be worthwhile to put a caching proxy in front of it to serve (semi)stale data for any preview request rather than impose additional load on the server just so a preview can be updated. So I can see at least two cases in which you might want to sniff the are you just previewing, or do you actually want the page information. Perhaps there are more. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On Dec 1, 2014, at 12:50 PM, Ned Batchelder n...@nedbatchelder.com wrote: On 12/1/14 4:26 PM, Tim Chase wrote: On 2014-12-01 11:28, 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. All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) This is the key point: your web application shouldn't be doing these kinds of actions in response to a GET request. Make them POST requests, and Safari won't give you any trouble. Trying to stop Safari from making the GET requests might work for Safari, but then you will find another browser, or a proxy server, or an edge-caching accelerator, etc, that makes the GET requests when you don't want them. The way to indicate to a browser that it shouldn't pre-fetch a URL is to make it a POST request. Ok, that makes sense. The only difficulty I have with that answer is that to the best of my knowledge the only way to make a HTML link do a POST is to use the onclick function to run a javascript, while having the link itself point to nothing. Just feels a bit ugly to me, but if that's the Right Way™ to do it, then that's fine. Thanks! -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list --- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On Dec 1, 2014, at 1:12 PM, Tim Chase python.l...@tim.thechases.com wrote: On 2014-12-01 16:50, Ned Batchelder wrote: On 12/1/14 4:26 PM, Tim Chase wrote: All this to also say that performing non-idempotent actions on a GET request is just begging for trouble. ;-) This is the key point: your web application shouldn't be doing these kinds of actions in response to a GET request. Make them POST requests, and Safari won't give you any trouble. Though to be fair, based on the reading I did, Safari also pulls in the various JS and executes it too, meaning that merely (pre)viewing the page triggers any Google Analytics (or other analytics) code you have on that page, sending page views with a high bounce rate (looks like you only hit one page and never browsed elsewhere on the site). Additionally, if the target GET URL involves high processing load on the server, it might be worthwhile to put a caching proxy in front of it to serve (semi)stale data for any preview request rather than impose additional load on the server just so a preview can be updated. Right, and there are probably some URL's in my app where this may be the case - I still need to go back and audit the code now that I'm aware of this going on. In general, though, it does sound as though changing things to POST requests, and disallowing GET requests for those URLS in my CherryPy app is the way to go. Thanks! So I can see at least two cases in which you might want to sniff the are you just previewing, or do you actually want the page information. Perhaps there are more. -tkc -- https://mail.python.org/mailman/listinfo/python-list --- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 --- -- https://mail.python.org/mailman/listinfo/python-list
Re: Cherrypy - prevent browser prefetch?
On 2014-12-01 13:14, Israel Brewster wrote: On Dec 1, 2014, at 12:50 PM, Ned Batchelder n...@nedbatchelder.com The way to indicate to a browser that it shouldn't pre-fetch a URL is to make it a POST request. Ok, that makes sense. The only difficulty I have with that answer is that to the best of my knowledge the only way to make a HTML link do a POST is to use the onclick function to run a javascript, while having the link itself point to nothing. Well, generally one would use a form where the method=POST and then the button/input submits it: form action=/path/to/my/url/ method=POST input type=submitThis is an inputinput /form or form action=/path/to/my/url/ method=POST button type=submitThis is a strongbutton/strong/button /form The advantage of a button is that it can contain rich content (other markup) while an input type=submit can't. To do a POST via an a tag, you do need (as you mention) to do some ugly jiggery with JavaScript, but tends to break the mental model. You should be able to style a button element to look much like a link if you find the visual effect of a button unpleasant. -tkc -- https://mail.python.org/mailman/listinfo/python-list
