Forum Discussion

trx's avatar
Feb 28, 2011

IRules causing certain browsers to crash

Hello All,

Has anyone experienced having their IRules/Virtual Servers (HTTP/HTTPS) to crash in an browser?




Error in IE 8 OS XP:




Internet Explorer cannot display the webpage




Any thoughts anyone on why this can happen?




Thanks in advance.








4 Replies

  • Crashing a browser is one thing, Giving a "cannot display page" error is another.



    Have you done a packet capture? Is the client receiving a RST from the Server (through the LTM)?
  • Sorry, I mean to say "error". Here is what I got from the logs:



    HTTP_REQUEST - Operation not supported. Multiple redirect/respond invocations not allowed line 137 invoked from within HTTP::respond 301 Location [string map {/portal/site } [HTTP::uri]]




    We are doing URL masking so it's kind of hard to NOT have multiple redirects. Any thoughts something else to try to prevent this?


    I continue to do some packet sniffing in the mean time.








  • Without knowing the full rule, it's a bit difficult. Can you post an anonymized version of your HTTP_REQUEST event and what you're trying to accomplish?
  • Hello ,

    I think it was a combination of too many 301 redirects and where the "return" syntax was placed in the code.










    if { ([string tolower [HTTP::uri]] contains "site_picker") or


    ([string tolower [HTTP::uri]] contains "create_profile") } {


    if user does NOT have access to the site, set the portal cookie flag to redirect


    if it exist


    if { ([HTTP::cookie exists $::portalCookie]) } {


    set ::portalExist 1






    } elseif { ([HTTP::uri] contains "/solutioncenter") } {


    set global variable flag for any old solutioncenter URL to 1


    and replace site names


    set ::SC_Flag 1


    HTTP::respond 301 Location [string map {"/solutioncenter" "/erp"} "[HTTP::uri]"]




    } elseif { ([HTTP::uri] contains "+") or ([HTTP::uri] contains "action.process") } {


    Allow VCM URLs and login actions to go through













    The issue seemed occur when their was ONLY 1 return syntax at the very bottom of the "HTTP_REQUEST" function.


    I would think it would NOT matter, but from testing, it seems to be case. Any thoughts?