Forum Discussion

Syed_Abuthahir_'s avatar
Syed_Abuthahir_
Icon for Nimbostratus rankNimbostratus
Jun 10, 2013

.Net Application - Post Back

We have a .NET Post back application that does not work on IE & Chrome. It works only in Firefox. We are calling IIS 7.5 servers through Big-IP F5 Load balancer using iRule mapping in F5.

 

 

Our Application does not work through this setup from Internet but works in Intranet without F5 setup in all browsers. Please support to resolve this issue.

 

 

6 Replies

  • At a minimum, what iRules you're using, what is breaking and how, per browser, what your environment looks like, and what the post back and other traffic looks like. The more detail you provide the better we are equipped to troubleshoot.
  •  

    ASP.NET Application does not work while submitting post action in form components like clear button, fetch dropdown data based on dynamic selection.

     

     

    This behavior of application is noticed only on Internet wherein traffic is routed through F5 iRule. But, works on Intranet

     

    wherein traffic is routed directly to IIS without F5.

     

     

    We are using IIS version 7.5 and Big-IP F5 LTM 10.4.4

     

     

     

    Observations from “Internet” with F5 LTM:

     

     

    o Internet Explorer - Not Working - Timeout & Request Aborted.

     

     

    o Mozilla Firefox - Working - Request & Response Success.

     

     

    o Google Chrome - Not Working - Timeout & Request Aborted.

     

     

     

    Observations from “Intranet” without F5 LTM:

     

     

    o Internet Explorer - Working - Request & Response Success.

     

     

    o Mozilla Firefox - Working - Request & Response Success.

     

     

    o Google Chrome - Working - Request & Response Success.

     

     

    As per above cases, we are suspecting the cause of issue on below F5 iRule that aborts application response through Internet.

     

     

    when HTTP_REQUEST {

     

    set uri [string tolower [HTTP::uri]]

     

    if {$uri contains "departmentwebsite" || $uri contains "requestservice"} {

     

    pool Pool_Department

     

    } elseif {$uri contains "iisservices"} {

     

    pool Pool_IIS

     

    } elseif {$uri contains ".ida" || $uri contains ".exe" || $uri contains ".dll"} {

     

    discard

     

    } else {

     

    pool Pool_http

     

    }

     

    }

     

  • Okay, now please do this. Modify your iRule to include some log statements and then test again and report your findings per browser. Make sure you follow the same actions in all of the browsers so that you can compare the results.

    
    when HTTP_REQUEST {
        set uri [string tolower [HTTP::uri]]
        log local0. "User-Agent: [HTTP::header User-Agent]"
        log local0. "Requesting: [HTTP::host]$uri"
        if {$uri contains "departmentwebsite" || $uri contains "requestservice"} {
            log local0. "uri contains departmentwebsite or requestservice"
            pool Pool_Department
        } elseif {$uri contains "iisservices"} {
            log local0. "uri contains iisservices"
            pool Pool_IIS
        } elseif {$uri contains ".ida" || $uri contains ".exe" || $uri contains ".dll"} {
            log local0. "uri contains .ida or .exe or .dll - discarding"
            discard
        } else {
            log local0. "else condition"
            pool Pool_http
        }
    }
    

    It may also be useful to run a wire capture (WireShark) or browser capture (Fiddler) on the client side to see what the traffic looks like, what is being requested, and when it fails.