uri query question

You could use the URI::compare command (Click here)

 

 

Bhattman

 

This looks like a bug. For the following test, I'd expect three empty results followed by the actual value of the aaa parameter. Instead, all the "a, aa, aaa" parameter names return the value of the aaa parameter:

 
  Tested on  
 when RULE_INIT { 
   set uri "/path/to/file.ext?aaa=111" 
   log local0. "\$uri: $uri" 
   log local0. "\[URI::query \$uri b\]: [URI::query $uri b]" 
   log local0. "\[URI::query \$uri a\]: [URI::query $uri a]" 
   log local0. "\[URI::query \$uri aa\]: [URI::query $uri aa]" 
   log local0. "\[URI::query \$uri aaa\]: [URI::query $uri aaa]" 
 } 
 

: $uri: /path/to/file.ext?aaa=111

: [URI::query $uri b]:

: [URI::query $uri a]: 111 <--- ?? this should be null

: [URI::query $uri aa]: 111 <--- ?? this should be null

: [URI::query $uri aaa]: 111

I'd suggest opening a case with F5 Support. In the meantime, you could manually parse the query string in a loop or using a regex:

 
     Loop through each parameter name looking for "param2" and log the name and value 
    set namevals [split [HTTP::query] "&"] 
    for {set i 0} {$i < [llength $namevals]} {incr i} { 
       set params [split [lindex $namevals $i] "="] 
       if {[lindex $params 0] eq "param2"}{ 
          log local0. "Param: [lindex $params 0], Value: [lindex $params 1]" 
       } 
    } 
 

In most regex flavors, you could use a lookbehind to match anything after the parameter name (param2 in this example):

(?<=(?:&|\?)param2=)[^&]*

Intead, you could use a combination of commands to get the parameter value (replace param2 with the actual parameter name):

Parse the value for the first "param2" parameter instance in the query string

set param_value [getfield [regexp -inline {(?:&|\?)param2=[^&]*} "?[HTTP::query]"] "=" 2]

I'm not sure which option would be more efficient. But I'd guess the loop might be more efficient for small numbers of parameters in the query string.

Aaron

Thank you both for replying. I won't be able to run the loop evaluation due to the high volume of queries and name/value pairs we deal with in each query but I will test out the other methods and hopefully get one of those working without impacting performance.

 

 

I have also opened up a case with F5 support asking them to evaluate this as well.

I'd push F5 for a hotfix as the workarounds can be quite CPU intensive. If you get a CR for this, can you reply with it here so others can attach cases to it as well?

 

 

Thanks,

 

Aaron

Actually I needed to fix this for a customer and came up with a workaround using findstr (Click here).

I'm guessing this would be faster than a loop or a regex. Replace $query with [HTTP::query] and update the skip count in the findstr commands based on how long the parameter name you're looking for is. You could calculate the skip count in the rule, but that would be less efficient.

 
 when RULE_INIT { 
  
     Find the value for the first instance of a parameter name of "aa" in the query string 
  
     Test query string 
    set query "aaa=111&aa=11&a=1&aa=22" 
  
     Test query string 
    set query "aa=11" 
  
     The parameter name to get the value for 
    set param_name aa 
  
     Check if query string starts with the parameter name and =. 
      Need to hardcode the length of the parameter name + 1 for findstr 
    if {$query starts_with "$param_name="}{ 
  
       log local0. "$param_name = [findstr $query "$param_name=" 3 &]" 
  
    } else { 
  
        Parameter wasn't at the start of the query string, so check for &param_name= in the query string 
         Need to hardcode the length of the parameter name + 2 for findstr 
       log local0. "$param_name = [findstr $query "&$param_name=" 4 &]" 
    } 
    log local0. "Incorrect value from URI::query: $param_name = [URI::query ?$query $param_name]" 
 } 
 

Aaron

This is a bug (CR137465). The problem is not that URI::query is doing a regex match, it's that it's essentially doing an "ends with" match, instead of the correct exact match.

There's a decent workaround; a bit of a hack, but nowhere near as slow as doing a loop.

 
  Make the first param start with a "&" to make it like the others 
 set uri [string replace [HTTP::uri] 0 0 "?&"] 
  Note the "&" in front of paramname! 
 set value [URI::query $uri &paramname] 
 

Nice one, Spark. Thanks for the tip.

 

 

So you could also try this:

 

 

[URI::query "?&[HTTP::query]" &param_name]

 

 

Not sure if it's any more efficient, but it's shorter

 

 

Aaron

Argh...gotta fix that. Sorry guys, makes for some confusing output, doesn't it?

Thanks to everyone for offering up alternate methods. I took some bits from the various methods and went this the approach below. We are evaluating its performance now.

 
 when HTTP_REQUEST { 
     set baseip 10.1.1. 
     set baseoctet 25 
     set basepool app_pool_1 
     set modulus 2  
  
     set uri [string map {?rx ?XXX-rx &rx &XXX-rx} [HTTP::uri]] 
     set key [URI::query $uri XXX-rx] 
  
     if {$key != ""} { 
         set maxkey [expr {$key + $modulus}] 
         for { set i $key } { $i < $maxkey} { incr i } { 
             set key [expr {$i % $modulus}] 
             set newoctet [expr {$baseoctet + $key}] 
             set memberip "$baseip$newoctet" 
             log local0.info "uri: $uri" 
             log local0.info "key: $key" 
             log local0.info "memberip: $memberip" 
             if { [LB::status pool $basepool member $memberip 80 ] eq "up" }{ 
                 pool $basepool member $memberip:80 
                 return 
             } 
         } 
     reject 
     } 
 } 
 

Apparently, the bug where you needed to add ?& to the front or the URI and & to the front of the parameter searched for was being tracked through this thread. The ticket was CR137465. In the Wiki text for URI::query, it says this is fixed in v 11, but I tried this on 11.4 and had to still use the workaround syntax. Can anyone confirm if the bug was actually fixed on v11?

 

Thanks,

 

Tom