favicon troubles keeps resulting in http 302 redirect

"The bigip always sends back a 302 redirect"? Don't you mean the real server? I assume it's the client requesting the favicon.ico too right? Can you provide some more detail on 'the session times out' please?

Sure, when we record the session from the client with Fiddler we see a 302 redirect form the bigip , it;s in the header information. What happens is a client logs on opens a PDF in a new tab of the browser and clicks on something in the previous tab. After that nothing happens and the session times out and produces an error page. Within Fiddler we see that a favicon.ico is being requested and is not found by the client. the 302 result is what we get after.

OK, interesting, why would the BIG-IP be sending the redirect? Do you have some iRules running? Are you using the cache?

Answer on your first question is: The BIG-IP sends the redirect because the favicon.ico is not to be found, we assume that this is the case. Yes, we have Irules running. But we already have tried without the Irules attached. We're using standard compression profile.

The F5 will not send a redirect unless it's configured to do so, as you've seen bigip in the Server HTTP header in the response to the client when it requests favicon.ico then it must be an irule sending it. I'd suggest you take a close look at the rule in question.

Note that removing the rules will not affect existing connections so I'd suggest you make sure you are opening a new connection/session when testing this (i.e. close your browser completely or use a completely different client et c.).

It appears to be an irule after all.. However, when we put in log rules, we see every time when a function is called in the browser is logged on the screen. At the very moment we click on the button on the first tab after having the second tab open, there's nothing logged on the screen. So our conclusion the Irule isn't hit am I correct? And we still see a 302 redirect is sent back to the browser from the Bigip how come?

It'll all depend on your iRule logic I guess. If you still get the 302 and the iRule isn't 'hit' then I'd suggest you check your (RAM) Cache Settings although as far as I'm aware 302 are not cached (301's are). Can you please do so and report back?

Btw, where does the redirect point to? Is the resource available?

I forget to mention that when the irule isn't used we have no problems at all.. How can we check ram cache settings?

Hi, webacceleration profile isn't used.

This is the irule which is causing the problem:

when HTTP_REQUEST
{
   set RequestedPath [string tolower [HTTP::path]]


   switch $RequestedPath
   {
      "/"
      {
         HTTP::redirect "https://x/north/"
      }
      "/north"
      {
         HTTP::redirect "https://x/north/"
      }
      "/south"
      {
         HTTP::redirect "https://x/south/"
      }
      "/north/"
      {
         HTTP::redirect "https://x/north/"
      }
      "/south/"
      {
         HTTP::redirect "https://x/south/"
      }

      default
      {
         if { !($RequestedPath starts_with "/n") }
         {
            HTTP::redirect "https://x/north/"

         }
      }
   }  
if { $RequestedPath contains "/north" }
   {   
if {[active_members Pool_x-north] > 0 }
      {
         pool Pool_x-north
      }
      else
      {
      if {[active_members Pool_www.y.nl] > 0 }
         {
            HTTP::redirect "http://www.y.nl/error/"
            TCP::close
         }

      }
   }
   elseif { $RequestedPath contains "/south" }
   { 
if {[active_members Pool_x-south] > 0 }
      {
         pool Pool_x-south
      }
      else
      {
         if {[active_members Pool_www.y.nl] > 0 }
         {
            HTTP::redirect "http://www.y.nl/error/"
            TCP::close
         }
      }
   }
}

OK, so, this is one weird iRule and it appears in places to be redirecting as well as trying to select a Pool which doesn't make sense! Could you explain the logic a bit please?