Forum Discussion
Help with K54399691 iRule
Hey everybody,
Maybe it's just me, but the phrasing in the K54399691 article makes my eyes cross... If I understand it correctly, I need to implement an iRule to capture the HTTP headers in a variable prior to APM processing, then pass the variable to the backend servers after APM allows access. I haven't had to write an iRule from scratch and frustratingly F5 doesn't provide any real guidance in the KB. This is probably a five minute fix, but I'm not at all confident what I'm trying to do is correct. With that in mind, the iRule below is likely wrong or they would have included something similar in the KB... Can anyone confirm whether I'm on the right track here or lend a hand getting me there? Any help is appreciated!
# When a POST is made, capture the original headers in "header" variable
when HTTP_REQUEST {
if {[HTTP::method] eq "POST"}{
set header [HTTP::header]
}
}
# When releasing the backend HTTP connection, send original headers
when HTTP_REQUEST_RELEASE {
set HTTP::header header
}
You are close, but the second method is wrong.
Use "ACCESS_ACL_ALLOWED" instead "HTTP_REQUEST_RELEASE".
- SuriAltostratus
Hey Whisperer,
That's funny... that was the original method I was going to use but found HTTP_REQUEST_RELEASE and changed it. If that works with the rest of what I'm doing then I guess huzzah? I'm just a little surprised that F5 wouldn't include a simple iRule like this in their KB... (hint, hint). I'll give it a test tomorrow. Thanks for the reply!
- SuriAltostratus
Alright, after a bit of fussing with syntax issues (and trying a couple alternative methods) our folks are testing with this iRule:
# When a POST is made, capture the original headers in "header" variable when HTTP_REQUEST { if {[HTTP::method] eq "POST"}{ set header HTTP::header } } # When APM allows access, set original headers when ACCESS_ACL_ALLOWED { set HTTP::header $header }
It sounds like it's working better, but if it requires some tweaking I'll update my post here so others can use this if needed.
- SuriAltostratus
Okay, so it turns out we were having another issue here. We found if the external application calling our F5 tried once it would fail, but the second try would succeed (with complete headers being passed). It didn't matter what the iRule did there, the behavior was the same. It seems what was happening is the app would hit the page and receive a 302 redirect to /my.policy which stripped the headers. We ended up creating an iRule that used Clientless Mode 3 which will still prompt for 401 authentication as desired, but prevent a 302 redirect to /my.policy. We targeted the specific URI that needs 401 authentication for this app to work, leaving other URIs with the default mode. After this change, the authentication succeeded and passed the backend headers and body as expected.
when HTTP_REQUEST { if {[HTTP::uri] starts_with "/desiredURI"} { HTTP::header insert "clientless-mode" 3 } }
__PRESENT
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com