Forum Discussion
CirrusChrome prefetch breaks APM sessions?
Hi,
We use Big-IP APM as a SAML SP for Shibboleth IdP. Our APM Policy is nothing too fancy. It's a multi-domain SSO.
The problem: we see a lot of /my.logout.php3?errorcode=21 in /var/log/ltm
In /var/log/apm we see this error: "Session deleted due to user logout request." This is not the case. The user did not ask for a logout. What probably happens, is that deep inside the APM functionality, an error happens (Invalid nonce) and then APM redirects to /my.logout.php3?errorcode=21.
So I did some digging. My results so far:
- Everytime this happens, there are two requests to /my.policy instead of one.
- Almost all (or all) of these requests are Chrome.
- For the latest version of Chrome (Chrome/69.0.3497.100), I almost always get the header "Purpose prefetch" on one of the requests.
- For all the older versions, Chrome 68 and older, I don't get the header.
So I assume it's all prefetch, and the latest Chrome identifies it as such. This leads me to some questions:
- Has anybody observed the same behaviour, and what were your solutions?
- Can this double requesting or prefetching break an APM session this way and why does Chrome prefetch /my.policy anyway. Is there any way to block this.
- Should I detect the prefetch call to /my.policy, can I safely send a 403? Or will this block both requests?
Thank you - I'm a bit stuck with this.
Vinne73https://groups.google.com/a/chromium.org/forum/!topic/blink-dev/IT3pYF5B_p4 - they say "In future releases we are introducing the “Purpose: prefetch” header to allow web servers distinguish prefetch traffic from user-initiated page load traffic."
So that confirms they were about to introduce the header.
- Vinne73
Some more info about todays logs, and the sessions that give errorcode=21. Every time, it's Chrome. And the most recent Chrome almost always sends the Purpose prefetch header.
Broken sessions: 13
Sessions with Chrome as browser: 13
Sessions with Purpose prefetch header: 10
Sessions without Purpose prefetch header: d95d4813 Chrome/69.0.3497.100 Mobile Safari/537.36 ae4b5aab Chrome/68.0.3440.106 Safari/537.36 112b7b65 Chrome/67.0.3396.99 Safari/537.36
Chrome User-Agents (all broken sessions):
5 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36. 1 Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36. 1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36. 1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36. 1 Mozilla/5.0 (Linux; Android 8.1.0; TA-1024 Build/OPR1.170623.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36. 1 Mozilla/5.0 (Linux; Android 8.1.0; Nexus 5X Build/OPM4.171019.016.A1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36. 1 Mozilla/5.0 (Linux; Android 8.0.0; SM-A320FL Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36. 1 Mozilla/5.0 (Linux; Android 7.0; SM-A520F Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36. 1 Mozilla/5.0 (Linux; Android 5.1.1; HUAWEI SCL-L21 Build/HuaweiSCL-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Mobile Safari/537.36. - Stanislas_Piro2
Cumulonimbus
You can try this code:
when ACCESS_SESSION_STARTED { if {[HTTP::header Purpose] equals "prefetch"} { ACCESS::respond 403 -version "1.1" noserver "Connection" "Close" ACCESS::session remove return } }it will drop new session if the Purpose header value is prefetch
Michel_HumphreyNimbostratus
Thanks .. this fixed it for us !
- Stanislas_Piro2
Thanks for the feedback. does it fix the same requirement (Purpose header with prefetch value) or is it a similar requirement base on other criteria?
- Michel_Humphrey
we were getting sporadic /my.logout.php3?errorcode=21. errors and this only on chrome .. version 69. Errors were accompanied of unexplained Null values in session variables that should of been populated..
after reading description of issues in this thread.. we figured that multiple queries might be happening for us too .. and parralell queries might the ones without populated variables.. hence the errors.. by essentially "killing" parallele querie.. it seemed to have fixed our issue. And as an unexpected result ... now our access policy also seems to run alot faster.. "snappier" .. i'm sure F5 code is ready for all new chrome features....
i want t osatte this conclusion is in no way scientific .. or by any means technically backed by anything but .. it did'nt work cleanly before the additionnal Irule code .. and now its predictable and snappy.
We did not go into traffic analysis to a level of waht is highlighted in Vinne73 post ..
- Marc-André_Mig1
When using the following CLI command "load sys config from-terminal merge" to copy the whole iRule with the code submitted by Stanislas, we got the following warning under build BIG-IP 12.1.3.6 Build 0.0.3 Point Release 6. This error is not caught under the configuration utility.
when ACCESS_SESSION_STARTED { if {[HTTP::header Purpose] equals "prefetch"} { ACCESS::respond 403 -version "1.1" noserver "Connection" "Close" ACCESS::session remove return } }
warning: [The following errors were not caught before. Please correct the script in order to avoid future disruption. "unexpected token(s): ' Connection Close'"1146 65][ACCESS::respond 403 -version "1.1" noserver "Connection" "Close"]
Should we be worries about it?