Browser type deciscion for redirect?

Hi Scott,

You can get the User-Agent header value using HTTP::header. To disable the HTTP profile you can use HTTP::disable. Without knowing what the issue is, it's hard to say this approach will fix the problem. But here is an example to implement the logic you've outlined.

 
 when HTTP_REQUEST { 
  
     Check if the client is an Opera browser 
    if {[string tolower [HTTP::header value User-Agent]] contains "opera"}{ 
  
        Disable the HTTP profile 
       HTTP::disable 
  
        Select an Opera-specific pool 
       pool opera_pool 
  
    } else { 
  
        Client isn't using Opera so enable the HTTP profile 
       HTTP::enable 
  
       Select the default pool 
      pool default_pool 
    } 
 } 
 

Aaron

thanks! we will give it a try.

Aaron,

 

i put that in place and if it isnt an opera browser it works, however if it is an opera browser it doesnt work - just clocks. previously it worked for both - prior to the irule. i am rechecking it to ensure i didnt mess anything up.

 

 

as for the issue, it appears with compression enabled the opera browser will randomly display garbled text. (big deal for our company since the WII uses the Opera browser) a refresh usually resolves it. it is random pages and random times but easily recreated.

as for the clocking it appears the http::disable causes issues with both browsers. does that make sense? when i comment it out, it loads yet it is still broke.

 

 

i moved the disable to the other browser and it did the same thing. clocked and wouldnt work.

I think it would be helpful to get a clear idea of the symptoms of the problem before trying to use an iRule to change things. If you have a support contract, this is something F5 Support should be able to help you troubleshoot. It would be helpful to capture a tcpdump on all interfaces the traffic passes through on. Remove any iRules, enable a basic HTTP profile without caching/compression enabled. Try to capture a single TCP connection in one dump where it works (text isn't garbled), and another request which fails in a second tcpdump.

 

 

You can use a command like this to save a tcpdump trace to a binary file:

 

 

tcpdump -ni 0.0 -s0 -w/var/tmp/`hostname`.opera.broken.dmp host CLIENT_IP or host SERVER_IP

 

 

If you have multiple servers in the pool, you can either add them to the end of the tcpdump command using 'or host SERVER_IP_2', or you can disable them and just trace on one server IP.

 

 

If you do figure out an iRule is required, reply here and let us know.

 

 

Aaron

Thanks Aaron. I do have a case and I have provided the dumps to the tech, waiting for a response. I have emailed my local rep, with his Support engineers for their suggestions, and wait both sides. While i agree with your assesment - which is what we are trying to do, I am trying to come up with an alternative or a workaround that may end up being the end result (F5 TS feels it is something in the profile but we havent pinpointed it). As I have also already proven that something in there is the issue. As far as removing irules, and enabling a basic HTTP profile that isnt realistic in my case. I did create an additional vip, and profile to test with. Main issue with the dumps is tech wanted vip to pool dump as well. I have done this three times now resulting in 1gig, 500MB and 400MB capture files. At any rate, just catching pressure here to get this resolved due to the nature of this site and the implications of the issue and its effect on customers.

 

 

I appreciate your quick response. Still not sure why disabling the http profile would cause an issue on either browser type.

Fair enough. Typically, you'd disable the HTTP profile before the request is parsed as HTTP in the CLIENT_ACCEPTED event or CLIENT_DATA. I'm not sure what impact there would be if the headers are parsed and then you disable the parsing of the rest of the HTTP in HTTP_REQUEST. Maybe someone else can add something here?

 

 

As for the tcpdumps, you could configure a unique SNAT address (anything but automap) for the BIG-IP to use only for your test VIP. You can then isolate both the client and serverside connections to minimize the tcpdump sizes.

 

 

Aaron

Thanks for the follow up. Still have not heard from tech support but it looks like we found the issue. It appears the chunking settings was doing it. Our chunking settings were "Preserve" and I changed it to Rechunk. I was able to change it, resolve the issue, change it back and recreate the issue. We put this into production and it works on the WIIs as well.

 

 

Thanks for the tip on the SNAT. I didnt even think of that. I will keep that for the next time I need that type of tcpdump.

 

 

That's interesting. I wonder why it was so intermittent then. I wouldn't have thought that one time it would answer with chunked encoding and another time with a content-length when answering the same type of request.

 

 

Anyhow, I'm glad you figured it out.

 

 

Aaron

yea. if you think your confused.... i am a router/switch guy stuck with the duties of the f5 so i don't know too much in depth about http. not that a router/switch guy couldnt. i guess i just havent..

 

 

thanks again!