An Issued Challenge…Again
It’s FSE iRules Challenge time again, folks, so strap on your geek-hats and follow along. First, before I get too deep into what the challenge actually was this time around, I want to steal a word or two from the last challenge’s announcement to describe what an FSE is.
FSEs are the engineering lifeblood of the sales force here at F5. They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world. I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules. Those that choose to flex those muscles garner a special place in my encrypted little heart. Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation.
Now that you know who they are, let’s take a look at what they’ll be doing this time. Given the success of the last challenge and the killer feedback we got about how it helped those folks learn and investigate the awesomeness that is iRules, Clint reached out again for another challenge. Any time I get a chance to get more people involved in the iRule community, teach them how to write some of this wicked cool code, and get them tearing through DevCentral to research fixes to problems they might have, I’m game. As such I was more than happy to provide just that in iRules Challenge form. Here it is, the new iRule FSE challenge:
Requirements:
1.Store a list of 50 unique “add strings” (a string of random text accompanied by a URL, intended to simulate a list of specials a site might want to advertise to incoming users) in a manner that makes them easy to update and retrieve.
2.Re-write all instances of “##InsertAddHere##” (case insensitive) with a randomly selected “add string” in the payload of every HTTP response that contains “##InsertAddHere##”.
3.Scrub all possibly harmful HTTP headers before reaching the client. Ensure that these headers are not blocked: "Host“, "Cache-Control“, "Connection“, "Content-Encoding“, "Content-Disposition“, "Content-Type“, "Content-Range“, "Content-Length“, "Date“, "ETag“, "Expires“, "Keep-Alive“, "Location“, "Pragma“, "Range“, "Set-Cookie“, "Transfer-Encoding“, "Vary“, "WWW-Authenticate“, "Age“, "Accept-Ranges“
4. Ensure that all users attempting to access http://domain.com/users/login are only allowed to do so via HTTPS.
The intent, much like last time, is to challenge these relatively new F5ers enough to make things interesting, but not soul crushing. Ideally they’ll reach out, research, and conquer. This isn’t intended to draw out the most intricate, challenging, mind-bending iRules known to man. It’s intended to force people (did I say force?) to get their feet wet and figure things out in a hurry. Hopefully it’ll do just that. Worth noting is my horrible spelling (due to this being written up while prepping for my day trip to Minneapolis for the User Group there) of “ad”. I meant “ad” as in advertisement, not “add” as in “addition”. Oh well, now that the challenge is issued there’s nothing that can be done but crack bad jokes about it, so have at it.
The results are due a week from today, so don’t go posting your solutions just yet. Hopefully, though, this will get your brain churning on how to solve these things. There will be prizes given out to the most successful FSEs that complete the challenge, and if you want to play along I’ll mention the top 3 user contributed iRules as well when it comes judging time next Friday.
A big thanks to everyone that’s participating. Now get to iRuling!
#Colin