Users are not able to edit the web page on web server while traffic passes through the Load Balancer

It's difficult to say without knowing more about the application. It's also certainly possible that some kinds of access are blocked through the load balancer because of authentication requirements or other proxy-related issues. I think the next step in troubleshooting this needs to be a comparison of the communicated protocol data across the two paths. The easiest approach would probably be a client side capture process like Fiddler or HTTPWatch. What you're looking for, essentially, is a marked differences between the two paths. You might see an authorization header in the direct path that you don't see in the other. You might see the app sending absolute references to itself (and local objects) using its internal name. Specifically look at what happens when you engage the edit function(s).

Please report back what you find.

Hi, Thanks for this.

I have installed HTTP Watch and found that the requests are not initiated. In the working websites following is the out put i am getting in HTTP Watch. From the below url, i think authentication starts. https://thatwasentme.com/irj/servlet/prt/portal/prtroot/com.btexx.pct.easyWCM.EditModeRegistrationComponent

https://thatwasentme.com/irj/portal?NavigationTarget=navurl://ce8094431fe6aa864a424b60e26ef4e6

https://thatwasentme.com/irj/portalapps/com.sap.portal.design.portaldesigndata/themes/portal/moon_water_redesign/glbl/glbl_ie6.css?7.0.20.0.2

https://thatwasentme.com/irj/portalapps/com.sap.portal.design.portaldesigndata/themes/portal/moon_water_redesign/prtl_std/prtl_std_ie6.css?7.0.20.0.2

https://thatwasentme.com/irj/portalapps/com.sap.portal.epcf.loader/script/optimize/js13_epcf.js?7.00001620

https://thatwasentme.com/irj/portalapps/com.sap.portal.pagebuilder/scripts/pagesupport.js

https://thatwasentme.com/irj/portalapps/com.sap.portal.design.portaldesigndata/themes/portal/moon_water_redesign/prtl/prtl_ie6.css?7.0.20.0.2

https://thatwasentme.com/irj/portalapps/com.tw.lightframework/css/masthead.css

https://thatwasentme.com/irj/portalapps/com.tw.lightframework/scripts/LightMastheadSlim.js

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM.gui/css/xtheme-gray.css?ewcVersion=4_0+SP2+Patch1_201003311654

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM.gui/css/all/btexx-ewc-all.css?ewcVersion=4_0+SP2+Patch1_201003311654

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM.gui/scripts/btexx-ext-221.js?ewcVersion=4_0+SP2+Patch1_201003311654

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM.gui/scripts/locale/ext-lang-en_GB.js?ewcVersion=4_0+SP2+Patch1_201003311654

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM.gui/scripts/btexx-ewc-all.js?ewcVersion=4_0+SP2+Patch1_201003311654

https://thatwasentme.com/irj/servlet/prt/portal/prtroot/com.btexx.pct.easyWCM.LocalizationController?ewcVersion=4_0+SP2+Patch1_201003311654&command=getResourceScript&country=GB&language=en

https://thatwasentme.com/irj/portalapps/com.sap.portal.navigation.contentarea/scripts/light_workArea.js

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/global.css

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/main.css

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/header4.css

https://thatwasentme.com/irj/portalapps/com.moonwater.frw/scripts/cookies.js

https://thatwasentme.com/irj/portalapps/com.moonwater.frw/scripts/framework_anonymous.js

https://thatwasentme.com/irj/portalapps/com.moonwater.frw/scripts/framework_authenticated.js

https://thatwasentme.com/irj/portalapps/com.btexx.pct.easyWCM/scripts/utilbase.js

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/js/jquery-latest.min.js

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/js/jquery.easing.1.2.js

https://thatwasentme.com/irj/go/km/docs/documents/TWDocumentBase/Corporate%20Communications%20Published/Images/Images%20for%20homepage%20news/football.jpg

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/js/jquery.easing.1.2.js

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/js/jquery-latest.min.js

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/main.css

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/header4.css

https://thatwasentme.com/irj/go/km/docs/documents/easyWCM/css/global.css

https://ssl.google-analytics.com/__utm.gif?utmwv=5.4.5&utms=3&utmn=748399580&utmhn=thatwasentme.com&utmcs=utf-8&utmsr=1366x768&utmvp=1345x218&utmsc=32-bit&utmul=en-us&utmje=1&utmfl=11.2%20r202&utmdt=Home%20-%20My%20homepage&utmhid=1154667132&utmr=https%3A%2F%2Fthatwasentme.com%2Firj%2Fportal&utmp=%2Firj%2Fportal%3FNavigationTarget%3Dnavurl%3A%2F%2Fce8094431fe6aa864a424b60e26ef4e6&utmht=1381342720144&utmac=UA-26515733-1&utmcc=__utma%3D153161853.1135980206.1381342636.1381342636.1381342636.1%3B%2B__utmz%3D153161853.1381342636.1.1.utmcsr%3Dtestthatwasentme.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Firj%2Fportal%3B&utmu=q~

https://ssl.google-analytics.com/ga.js

But this is the output of the working site. for the new one I created has irule as follows:

when HTTP_REQUEST { HTTP::redirect "https://[HTTP::host][HTTP::uri]" }

which redirects traffic from http to https. When i use this irule the website issue starts and nothing happens when we click on the button which takes us on the page to edit the website.

So all these transactions are not starting at all when i have an iRule for http to https iRule applied to the virtual server.

The iRule you're presenting indicates that you have TWO virtual servers: the HTTPS VIP that sends to the application, and the HTTP VIP that simply redirects requests to the HTTPS VIP. This iRule should NOT be on your HTTPS VIP. Assuming it isn't, what happens if you try to access the VIP using HTTPS?

Hi Kevin,

That iRule is on the Virtual Server listening on port 80. It is not applied to VS listening on HTTPS.

This was a solution give by a TAC Engineer because there are some sites in the portal which are http. So if I configure a VS with HTTPS, those URLs are not opening.

If I use only one VS listening on Port 80, everything works well but cust is not ready for that because of security reasons.

Any solution for these...

Your iRule doesn't let any traffic pass - it simply redirects all requests to the HTTPS VIP as they come in. Do you need to allow some HTTP traffic to pass?

If you go directly to the HTTPS VIP, do you see any traffic in your captures trying to go to the HTTP VIP?

Yes, Some URLs are http. This is the reason when we have not applied the second VS listening on port 80, some of the URLs were not working.

Okay, the picture is getting clearer. So is it safe to say that this broke when you applied the iRule?

Yes kevin, thats clear now.

1) If I use http only, everything will work fine. But custometr is not al,lowing that 2) If i use HTTPS some URLs won't open (which are https in the web server). 3) When I redirect to achive both, the edit functionality dont work.

need some solution or some advice that will allow me achieve both,means the edit functionality should work when i redirect the urls from http to https.

Any help would be a game changer for me here. Pls suggest.

Okay, so I'm now assuming that the web server is responding to the client with HTTP references and that these HTTP references can't be accessed based on your current rule. If that's the case, perhaps the simplest approach would be to rewrite the HTTP references as HTTPS references as they pass through the F5. The first example code on the STREAM::expression wiki page should be a good place to start. Use this iRule on your HTTPS VIP and apply an empty STREAM profile.

https://devcentral.f5.com/wiki/iRules.STREAM__expression.ashx

If this works, you shouldn't need the HTTP VIP as all requests should be forced to the HTTPS VIP.

Hi Kevin,

I have used foollowing I Rule but seems that its not working. The first page itself is not opening.

Example which replaces http:// with https:// in response content Prevents server compression in responses

 
when HTTP_REQUEST { 

        #Disable the stream filter for all requests 

   STREAM::disable

    #LTM does not uncompress response content, so if the server has compression enabled 
    #and it cannot be disabled on the server, we can prevent the server from  
    #sending a compressed response by removing the compression offerings from the client 
   HTTP::header remove "Accept-Encoding"
} 
when HTTP_RESPONSE { 

    #Check if response type is text 
   if {[HTTP::header value Content-Type] contains "text"}{ 

       #Replace http:// with https:// 

      STREAM::expression {@http://@https://@} 

       #Enable the stream filter for this response only 
      STREAM::enable
   } 
}