HTTP::uri causes malformed URI
We are using the HTTP::uri command in an iRule to set a prefix on the given URI, and following the prefix example given in the F5 official documentation shown here: https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/ltm/ltm_rule_command_HTTP_uri.html The exact iRule we're using is this: when HTTP_REQUEST { set uri [string tolower [HTTP::uri]] if { $uri starts_with "/firstPath/" or $uri contains "/secondPath" }{ HTTP::uri /thirdPath[HTTP::uri] pool poolA } elseif { not ([HTTP::uri] starts_with "/otherPath") } { HTTP::uri /otherPath[HTTP::uri] pool poolB } } This works as expected, except one request from a single known source results in a bad URI. The elseif part that applies the prefix is the part that isn't working consistently. We've had this occur in two different environments across different LTMs on the same type of request. The provided request URL is something like: https://www.company.com/foo/bar We expect the URI to be rewritten as: /otherPath/foo/bar But in fact the rewritten URI ends up as: /otherPathhttps:/www.company.com/foo/bar This specific request is coming in as POST HTTP/1.0. I'm not a network engineer so I don't know if there's anything somewhere else on the LTM that would be affecting this type of request, or if there's something else this specific request could be hiding that would cause the iRule to behave this way. The LTMs are all running version 15.1.3.1.
Matching ASCII codes %00 - %1f in HTTP::uri
According to: http://www.w3schools.com/tags/ref_urlencode.asp "The ASCII device control characters %00-%1f were originally designed to control hardware devices. Control characters have nothing to do inside a URL." A vendor software has a bug that actually interprets %00-%1f and does some fateful things on the system as a result. I have the vendor software behind the LTM, and want to close the TCP connection for all URLs with these ASCII codes, particularly "%00". What is the best approach to do this? I tried the below block of code, but the request with "%00" in the URI is not being caught in the IF statement. when HTTP_REQUEST { if { [HTTP::uri] contains "%00" }{ HTTP::close TCP::close } }
BIG-IP : iRule case-insensitive query-param matching
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi In my iRule I wish to identify the value of a query-param that may or may not be present. I'm using this logic : set myparam 0 set myparam [URI::query [HTTP::uri] myparam] However, I'm finding that URI::query performs case-sensitive matching. For example, if my request is : http://www.mysite.com/hello?myParam=1 then the myparam variable will not be set. Howe can I perform case-insensitive matches of query-params ?HTTP::uri always includes trailing slash ?
BIG-IP 11.4.0 Build 2384.0 Final I am finding for requests with a single segment path such as : http://www.mysite.com/myresource HTTP:uri always appends a trailing slash : HTTP:uri = "/myresource/" Is this expected behavior ? Why does BIG-IP do this ? NOTE: At the very beginning of my iRule , I write HTTP::uri to the local log , and the trailing slash is already present -- so it is not my iRule that is adding it.BIG-IP : rewrites using HTTP::uri
BIG-IP 11.4.0 Build 2384.0 Final I've seen examples where a rewrite is accomplished as follows : HTTP::uri "http://www.mydomain.com/folder/page.html" Which seems to work -- but I find this strange because it includes the host. It seems more logical that host and uri be set separately : HTTP::host "www.mydomain.com" HTTP::uri "/folder/page.html" Or what exactly is the recommended form ? Thanks.