Proc for fully decoding URI's

not sure if i understand correctly. you want to make FullyDecodeURI proc, don't you?

e.g.

 config

[root@ve11a:Active:In Sync] config  tmsh list ltm rule qux
ltm rule qux {
    proc decode_uri { uri max } {
  set cnt 0
  set tmpuri [URI::decode $uri]

  while { $uri ne $tmpuri && $cnt < $max } {
    set uri $tmpuri
    set tmpuri [URI::decode $uri]
    incr cnt
  }
  return $tmpuri
}
when HTTP_REQUEST {
  set uri [call decode_uri [HTTP::uri] 10]
  log local0. "URI=[HTTP::uri] decoded URI=$uri"
  HTTP::uri $uri
}
}

 /var/log/ltm

[root@ve11a:Active:In Sync] config  tail -f /var/log/ltm
May 17 21:01:51 ve11a info tmm[14715]: Rule /Common/qux : URI=/%20something%20bha%20bha%20bha decoded URI=/ something bha bha bha

not sure if i understand correctly. you want to make FullyDecodeURI proc, don't you?

e.g.

 config

[root@ve11a:Active:In Sync] config  tmsh list ltm rule qux
ltm rule qux {
    proc decode_uri { uri max } {
  set cnt 0
  set tmpuri [URI::decode $uri]

  while { $uri ne $tmpuri && $cnt < $max } {
    set uri $tmpuri
    set tmpuri [URI::decode $uri]
    incr cnt
  }
  return $tmpuri
}
when HTTP_REQUEST {
  set uri [call decode_uri [HTTP::uri] 10]
  log local0. "URI=[HTTP::uri] decoded URI=$uri"
  HTTP::uri $uri
}
}

 /var/log/ltm

[root@ve11a:Active:In Sync] config  tail -f /var/log/ltm
May 17 21:01:51 ve11a info tmm[14715]: Rule /Common/qux : URI=/%20something%20bha%20bha%20bha decoded URI=/ something bha bha bha

you are saying just move the regular irule portion of FullyDecodeURI from codeshare that uses a backstopped while loop and use the new Procedure functionality to have it declared just once and callable.

yes. i do not think URI::decode is connection-aware command.

Does it change in terms of the rules followed to decode based on if an HTTP::query or HTTP::uri or HTTP::host is passed in

do you mean the decode result? i understand it is only a command return (i.e. no change to object which is passed in).

If I may add, the URI::decode command is actually a string-level parser. You could just as easily use it like this:

when RULE_INIT {
    set uri "/something%20something%20something/blah"
    log local0. [URI::decode $uri]
}

What you couldn't do is use a protocol-level command, like HTTP::uri, inside a proc. Otherwise a proc is just a function that takes inputs and returns an output. There are of course going to be exceptions to this rule, but you can mostly say that any command that's prefixed with a specific protocol (ie. HTTP::, DNS::, SSL::, TCP::, etc.) isn't going to be directly accessible inside a proc. Anything else is either fair game or can be passed in as a parameter.

Thanks for clarifying this and confirming that HTTP:: TCP::, etc commands are offlimits in proc's even if the HTTP_REQUEST event or CLIENT_ACCEPT is calling the proc

I would just add that this shouldn't be a problem. You generally need a protocol-level event to trigger iRule processing, so whatever data is accessible in that event can be sent to the proc as a parameter. A dirty example:

proc doSomethingWithUri { uri } {
    set foo [URI::decode $uri]
    return $foo
}
when HTTP_REQUEST {
    if { [string tolower [HTTP::uri]] starts_with "/app1" } {
        set ret [call doSomethingWithUri [HTTP::uri]]
        log local0. $ret
    }
}