Browser Cookie Support Required iRule Using Modernizr

Problem this snippet solves:

Validates (using JavaScript) that the client browser supports cookies before continuing. It's a good idea to back up the Modernizr script libraries and store them locally in case something happens to them.

There is an exception for OPTIONS HTTP requests. This was a requirement in our environment, because there was an inbound application that could not accept cookies. The saving grace is that they told me they were using OPTIONS instead of GET, so I was able to create an exception to bypass the iRule. You'll want to keep this in mind in case you run into similar scenarios.

Feedback or suggestions are welcome.

How to use this snippet:

The iRule MUST be in last position of order. For some reason it doesn't work otherwise.

This site was damaging the code. You can download it as txt.zip or retrieve it from my first comment.

Shoutout to my webdev coworker for supplying the JavaScript portion, which I tweaked a bit and added the alert to. "If only there was some way to force the client to reload the page," I mused. Doh!

Code :

69783

Tested this on version:

11.5
Published Aug 02, 2016
Version 1.0
application delivery
browser
cookies
devops
iRules
LTM
validate
  • Jer-O's avatar
    Jer-O
    Icon for Cirrus rankCirrus
    Aug 02, 2016
    author: Jer O. devcentral.f5.com/users/175899
title: Browser Cookie Support Required iRule Using Modernizr
notes: PLACE THIS IRULE IN THE LAST POSITION ONLY (I suggest stating this in your iRule title)
when HTTP_REQUEST {
 if { [HTTP::cookie count] equals 0 and not ( [HTTP::method] contains "OPTIONS" ) } {
  HTTP::respond 200 content {
   
   
   
   
   
   
   
   
  } noserver
 }
 else { return }
}
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Aug 03, 2016

    The snippet looks very elegant! 🙂

    Note: To make the ordering of the iRules more robust, you could tweak the iRule a little bit, so that your iRule could be assigned with the highest priority (would make much sense to check this iRule before processing other iRules, right?).

    Just issue a 

    event disable all
    and 
    TCP::close
    right after 
    HTTP::respond
    to stop further iRule processing on the current TCP connection and to get rid of possible "Operation not supported. Multiple redirect/respond invocations not allowed.." error messages.

    If you want o stick with the approach to assign the lowest priority to your iRule, then you may want to include a 

    if { [catch {HTTP::payload replace 0 0 {}}] } then { return }
    check at the beginning of this iRule to see if other iRules with lower priorities had already responded the HTTP request (e.g. some Redirect) to avoid the "Operation not supported..." error messages.

    Cheers, Kai

  • JoshBecigneul's avatar
    JoshBecigneul
    Icon for MVP rankMVP
    Sep 09, 2016

    I'm not clear on what purpose Modernizr is serving. It seems like js.cookie is doing everything needed? I disabled it in a test scenario I built and it seems to function even if it's commented out.