Forum Discussion

JamesS_40157's avatar
JamesS_40157
Icon for Nimbostratus rankNimbostratus
Aug 29, 2012

Try next irule (or different virtual server) if 404 response

Hi,

 

 

We are currently implementing a new virtual server to replace a legacy one, essentially it is a giant media (image) server. The legacy virtual server has a quite complicated irule in place to serve the images. I have crafted an irule for the new virtual server to take care of various bits and pieces for the new architecture, however during migration it is possible that not all media/images will be available on the new virtual server, but will definitely exist on the old. I'm therefore trying to find a way to seamlessly always serve the correct content to the user without noticing any redirects.

 

 

Essentially what I would like to do is say, if a 404 is returned from the new virtual server backend node, to instead try the legacy virtual server - this should be seamless to the client and look like a simple GET request and 200 response.

 

 

Is this possible? I have tried adding a clause in the HTTP_RESPONSE event for the new virtual server irule to say if a 404 is received then to set the virtual server to the legacy one (which has extra irules on it) but this does not work.

 

 

I have thought about placing the legacy irule below that of the new irule on the new virtual server, however I can't work out how to get (in the case of a 404 response) the current irule to "exit" and fall down to the legacy irule. I would prefer not to merge the two irules together as they are both reasonably large and complicated! I need to find a way to "trap/catch" the 404 response, and get the load balancer to re-request the URI but to the legacy virtual server. Any ideas are much appreciated!!

 

 

Thank you :)

 

James

 

 

application delivery
dev
devops
iRules
  • JamesS_40157's avatar
    JamesS_40157
    Icon for Nimbostratus rankNimbostratus
    Aug 29, 2012
    Isn't it funny how sometimes when you post a question you immediately think of the answer? :)

     

     

    For future ref for anyone who might need it...

     

     

    Within HTTP_RESPONSE:

     

    if { $partition eq "prod" && ([HTTP::status] eq "404") } {

     

    if { $debug>=3 } { log local0.info "$castoruri not found in $partition castor domain. Falling back to legacy irule" }

     

    set trylegacy 1

     

    HTTP::retry $request

     

    }

     

     

     

    within HTTP_REQUEST:

     

    if { [info exists trylegacy] && $trylegacy == 1 } {

     

    if { $debug>=3 } { log local0.info "LEGACY REQUEST INITIALISED for $castoruri in $partition castor domain" }

     

    virtual legacyvirtual

     

    return

     

    }
  • Joe_Pruitt's avatar
    Joe_Pruitt
    Aug 30, 2012
    Colin and I just discussed this post on my most recent Post of the Week.

     

     

    https://devcentral.f5.com/Multimedia/DCTV/Player/TabId/1086258/VideoId/2076/DevCentral-Post-Of-The-Week-20120830.aspx

     

     

    The one thing I would add would be to toss in a "unset trylegacy" in the HTTP_REQUEST logic. For the cases where a keep-alive connection occurs, you may have the variable set from a previous request and it won't be wanted for a subsequent request for a new image that may be on the new virtual but you will still get routed back to the old one due to the lingering variable.

     

     

    -Joe