Forum Discussion

mattdereus's avatar
Icon for Nimbostratus rankNimbostratus
Mar 18, 2022

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:

The exact iRule we're using is this:


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: 
We expect the URI to be rewritten as: /otherPath/foo/bar
But in fact the rewritten URI ends up as: /otherPathhttps:/

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

2 Replies

  • Hi mattdereus ,

    I would recommend either adding some logging commands to this rule or grabbing one of the rules available that dumps info about the request to fully understand the state of the requests that show that issue.

    There is an older post, "HTTP::uri returns full URL" in which they were seeing something similar to you, and one of the commenters mentioned that RFC2616 allows for an absolute URI in certain cases. One of the suggestions is to check to see if the URI begins with a /, and if not, then you could use the URI:: commands to get and modify the path in the URI as you need.

    Hope this helps,