Forum Discussion

Matt_85761's avatar
Matt_85761
Icon for Nimbostratus rankNimbostratus
Feb 13, 2012

HTTP::respond on SSL virtual server

Hi all

 

 

I'm a bit of an f5 veteran but this is my first post in devcentral...

 

 

 

BIG-IP 10.0.1 Build 378.0

 

 

 

 

I have 2 virtual servers for the same host, one SSL the other not. They currently serve a production site I don't want to impact, however two pages needs to be redirected to an entirely new site based on the URI.

 

 

 

I wrote a simple redirect iRule - probably the most simplest I've written yet it's bugging the heck out of me - it successfully redirects the client for the HTTP virtual server but results in an SSL error when a user hits that specific URL on the SSL virtual server:

 

 

 

when HTTP_REQUEST {

 

if { [HTTP::uri] starts_with "/olduri1" }

 

{ HTTP::respond 301 Location "https://newhost/newuri1" }

 

if { [HTTP::uri] starts_with "/olduri2" }

 

{ HTTP::respond 301 Location " https://newhost/newuri2" }

 

 

 

 

Works for the non-SSL VS:

 

curl -I http://oldhost/oldurl1

 

HTTP/1.0 301 Moved Permanently

 

Location: https://newhost/newuri1

 

Server: BigIP

 

Connection: Keep-Alive

 

Content-Length: 0

 

 

 

 

But not for the SSL VS:

 

curl -Ik https://oldhost/oldurl1

 

curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104

 

 

 

 

What have I done wrong? I'm sure it's something really simple...

 

 

 

Matt

 

5 Replies

  • this is mine. it is 10.2.3.

    [root@ve1023:Active] config  b virtual bar list
    virtual bar {
       destination 172.28.19.79:443
       ip protocol 6
       rules myrule
       profiles {
          clientssl {
             clientside
          }
          http {}
          tcp {}
       }
    }
    [root@ve1023:Active] config  b rule myrule list
    rule myrule {
       when HTTP_REQUEST {
       if {[HTTP::uri] starts_with "/olduri1"} {
          HTTP::respond 301 Location "https://newhost/newuri1"
       }
       if {[HTTP::uri] starts_with "/olduri2"} {
          HTTP::respond 301 Location " https://newhost/newuri2"
       }
    }
    }
    
    [root@ve1023:Active] config  curl -Ik https://oldhost/olduri1
    HTTP/1.0 301 Moved Permanently
    Location: https://newhost/newuri1
    Server: BigIP
    Connection: Keep-Alive
    Content-Length: 0
    
    
  • Thanks nitass - I just did the same in 10.0.1 with the same results... :/

     

     

     

    There was another iRule bound to the VS with the following statement:

     

     

     

    if { [HTTP::uri] starts_with "/o" } {

     

    HTTP::header replace Host "oldhost.company.com"

     

    set ::SelectedPool "old_pool"

     

    }

     

     

     

    This was also being matched for oldhost/olduri1. Shouldn't have mattered... the redirect worked for the HTTP virtual but not HTTPS.

     

     

     

    Anyway I ended up integrating both rules, and nesting the old iRule as an else clause within a new iRule... so the header replacement and pool selection statement would never trigger if the redirect was hit.

     

     

     

    when HTTP_REQUEST {

     

    if {[HTTP::uri] starts_with "/olduri1"} {

     

    HTTP::respond 301 Location "https://newhost/newuri1"

     

    } elseif {[HTTP::uri] starts_with "/olduri2"} {

     

    HTTP::respond 301 Location " https://newhost/newuri2"

     

    } else {

     

    if { [HTTP::uri] starts_with "/o" } {

     

    HTTP::header replace Host "oldhost.company.com" set ::SelectedPool "old_pool"

     

    }

     

    }

     

    }

     

     

     

    Thanks for your help, sometimes all it takes is a simple test!

     

     

     

  • Hi Matt,

     

     

    Did you see any TCL errors in /var/log/ltm when the failure occurred? I imagine you would have gotten an error about an unsupported operation when trying to rewrite a header after calling HTTP::respond.

     

     

    Also what are you trying to do with this?

     

     

    set ::SelectedPool "old_pool"

     

     

    Most likely you don't want to be using a global variable to track which pool to use. A global variable will be referenced and updated across all clients and all connections.

     

     

    Aaron
  • But not for the SSL VS:

     

    curl -Ik https://oldhost/oldurl1

     

    curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104have you tried default clientssl profile? i understand it failed ssl handshake - not an irule.