LTM VE 10.2.3: HTTP::uri

There's no reason the HTTP::uri value can't be specified with a variable. However, you seem to be using the variable to create it, unless it's set previously in code you didn't post, i.e. 'set uriN [findstr $uriM "/delivery" 9]'

You are right. I forgot to include that part. Thank you

when HTTP_REQUEST { set SELECTED_POOL "LPAGE_DELIVERY_CMP" set uriM [HTTP::uri]

OK, try this, I've just added some logging, made the URI lowercase everywhere and reduced the size of the switch;

when HTTP_REQUEST {
    set originaluri [string tolower [HTTP::uri]]

    switch -glob [string tolower [HTTP::uri]] { 
        "/cm/" { 
            set SELECTED_POOL "LPAGE_ALERTAS"
        } 
        "/delivery/imanager" -
        "/delivery/wifi" { 
            set newuri [findstr $originaluri "/delivery" 9] 
            HTTP::uri $newuri
            set SELECTED_POOL "LPAGE_DELIVERY_CMP"
            log local0. "Rewriting URI from $originaluri to $newuri"
        } 
        "/delivery" { 
            set SELECTED_POOL "LPAGE_DELIVERY_CMP"
        }
        default { 
            HTTP::respond 403
            log local0. "No URI match, sending a 403 response"
        } 
    } 
}

I will try it as soon as possible, and back to you. Thanks a lot for your help.

Bad luck, it has NOT worked :-( It is a bit hard to explain what happens, but I'll try it the best I can. Here you have the irule: when HTTP_REQUEST { set DEBUG 1 set SELECTED_POOL "p_cmp_delivery_7002" set originaluri [string tolower [HTTP::uri]] switch -glob [string tolower [HTTP::uri]] { "/cm/" { set SELECTED_POOL "LPAGE_ALERTAS"

AND this is the log: Sep 16 09:33:30 62-87-22-161 tmm[4818]: Rule cmp_lpage_virtual_2 : LPAGE_APPLICATION URI MODIF:: /wifi/controllermenu.jsp?mid=secciones&afterredirect=true - /delivery/wifi/controllerMenu.jsp?mId=Secciones&afterRedirect=true ........... As you can see, $newuri is /wifi/controllermenu.jsp?mid=secciones&afterredirect=true, but [HTTP::uri] is still /delivery/wifi/controllerMenu.jsp?mId=Secciones&afterRedirect=true, that is, [HTTP::uri] does NOT change its value to $newuri, and I don't know why. How can I modif the value of [HTTP::uri]? Thanks in advance.

If I may add, the HTTP::uri write command, on most platforms, does not actually rewrite the client request URI in session state - it only changes the value on the outgoing payload. Your iRule is definitely changing the URI on its way to the server, you just won't see that change in [HTTP::uri].

Also not completely sure what you were doing with the SELECTED_POOL variable, so here's a minor rewrite:

when CLIENT_ACCEPTED {
     set default_pool to pool assigned to the virtual server
    set default_pool [LB::server pool]
}
when HTTP_REQUEST { 
    set DEBUG 1 
    switch -glob [string tolower [HTTP::uri]] { 
        "/cm/*" { 
            pool "LPAGE_ALERTAS"
        } 
        "/delivery/wifi*" { 
            set newuri [findstr [string tolower [HTTP::uri]] "/delivery" 9] 
            HTTP::uri $newuri 
            if { $DEBUG } { log local1. "LPAGE_APPLICATION URI MODIF:: $newuri - [HTTP::uri]" }
            pool $default_pool
        } 
        "/delivery*" { 
            pool $default_pool 
        } 
        default { 
            if { $DEBUG } { log local1. "LPAGE_APPLICATION :: blocked request for [HTTP::uri] by [IP::client_addr]" }
            HTTP::respond 403
        }
    } 
}

Do you mean the BIG-IP LTM cannot change the original URL (the URL the client asked for) by using HTTP::uri $newuri ? In this case, is the only solution to use 'redirect'? Thanks.

The HTTP::uri command is replacing the URI sent by the client.

Now, I understand what happens. The log message just reflects the received URI, and the replaced URI is really forwarded, as Stephan says. Thank you all for your help.

You may add the following event and log command to your iRule to monitor the modified URI:

when HTTP_REQUEST_SEND {
    log local0. "[clientside {HTTP::uri}]"
}

Use the following to monitor the LTM log facility, please:

tail -f /var/log/ltm