Forum Discussion

jim_sellers_436's avatar
Icon for Nimbostratus rankNimbostratus
Oct 13, 2010

Irule help - encoding

Hello all below is the issue to I am having and the irule we tossed together. I am trying understand if this is a possible bug with BIG-IP 9.3.1 Build 69.0.



I’ve attached the log output from a sample session. We’re getting the following (removed https:// to make the link not active and marked two sections in bold and blue to indicate where the error lies):



HTTP_REQUEST: newString2 1 {




If we plug in the missing ampersands and replace the encoded equals sign (3d) with an equals sign (red section) and percent signs (blue sections), we get the following:



That works perfectly. So, we just need to figure out why the & and = are being removed from $fssString and why the % signs are being removed from newstring2.




here is the rule we are using






log local0. "WebEx iRule HIT"


if {[HTTP::uri] contains "redirectWebEx"}{


your example string


set origString [HTTP::host][HTTP::uri]


log local0. "origString {$origString}"



break it up using ? as delimiter


Note use of '?' as url-split, instead of 'TARGET' - Allan


set tempString [split $origString "?"]


log local0. "tempString {$tempString}"



put back together anything past the first ?, aka the 'query string'


set queryString [join [lrange $tempString 1 end] "?"]


log local0. "queryString {$queryString}"



set value for FSS/Ping string


set fssString



build the new string using the F5 URI::encode command on the entire query string


set newString2 "[lindex $fssString 0][URI::encode $queryString]"


log local0. "newString2 1 {$newString2}"



HTTP::redirect $newString2




else {


log local0. "WebEx_irule_missed: [HTTP::uri]"








Thanks in advance !!!



7 Replies

  • It looks like you're using URI::encode to URL encode the query string. If that's not what you want to do, can you post the full logs from /var/log/ltm for a request, redirect and subsequent request that fails?



    Thanks, Aaron
  • That is correct Hoolio - we are trying to Percent Encode using the URI::encode function.



    The oddness (at least to us and our logged entry) is that our encoded string "newString2" seems to have all the percent-encoded AlphaNumeric changes - but the actual Percent sign is not preceding them. There's no Percent sign anywhere in our "encoded" string.



    Are we mis-understanding what should have happened or is this perhaps a minor bug of sorts? We expected to see the full https%3a%2f%2f (and other encodings) and all we got was "https3a2f2f". (no percent sign).



    That's at least one of the 3 minor issues we had with our iRule.



    The other 2 issues as Jim noted are that we lost our '&' and '=' from our original string. I hadn't looked at that yet but suspected that to be a more definitive error in our Rule, perhaps how we used SPLIT or LINDEX.
  • Hi Allan,



    Sorry for the confusion. I misread the original post. Can you post a sanitized example of the original URI and the desired redirect URL?



    Thanks, Aaron
  • [u[Original:[/b[}






    As you can see above - we are actually trying to do 2 things here. 1.) Change the Host.Domain and the URI string up to the word TARGET. 2.) Percent-encode the full URL after the word TARGET. (new app requirement)



    Once the URL is segmented and re-composed (newstring21), we then redirect the user to the new re-constructed URL.



  • an external source was able to validate our iRule on a different version of, that's good news for us right now.



    no bug reports were noticed but now waiting on official feedback for an F5 reponse to our issue.
  • Your external source is correct :-) I tested this on version v10 and v9.2 and it seems to be doing exactly what the irule is scripted to do. For some reason some of the ecoding is not working.



    Let us know how it turns out






  • URI::encode seems to work correctly on 9.3.1 and 10.2.0:



    when RULE_INIT {
    log local0. "[URI::encode]"



    Rule :



    I'm not sure what the issue is with the existing rule as I didn't step through it. But I think you can avoid some of the operations using inbuilt the URI::query and URI::encode functions:





     when RULE_INIT {
     This event is here just to show the intermediate values for the URI parsing
    set url_orig ""
    log local0. "\$url_orig: $url_orig"
    set target [URI::query $url_orig "TARGET"]
    log local0. "\$target: $target"
    set target_encoded [URI::encode [URI::query $url_orig "TARGET"]]
    log local0. "\$target_encoded: $target_encoded"
    set target_redirect "[URI::encode [URI::query $url_orig "TARGET"]]"
    log local0. "\$target_redirect: $target_redirect"
    when HTTP_REQUEST {
     Check if we need to rewrite this request?
    if {$some_condition == 1}{
    HTTP::redirect "[URI::encode [URI::query [HTTP::uri] "TARGET"]]"



    /var/log/ltm output from the test code in RULE_INIT:



    < RULE_INIT>: $url_orig:


    < RULE_INIT>: $target:


    < RULE_INIT>: $target_encoded:


    < RULE_INIT>: $target_redirect: