Forum Discussion

B_123334's avatar
B_123334
Icon for Nimbostratus rankNimbostratus
May 03, 2013

Traffic breaks coming back from https to http after enabling X-Forward header for weblogic server

F5 Version: BIG-IP v11.1.0 (Build 2185.0)

 

 

Current setup:

 

 

we have 2 virtual server configured ( one for http and another for https traffic). We can currently see client ip in our apache server logs after configuring X-Forward on apache httpd.conf for logs. We also created following irule to pass on the client ip to weblogic server(as suggested by oracle):

 

 

when HTTP_REQUEST {

 

HTTP::header insert WL-Proxy-Client-IP [IP::remote_addr]

 

}

 

 

When this irule is configured on both http and https virutal servers, we can go to http://mywebsite.com, and then to https://mywebsite.com, but when we try to come back to http://mywebsite.com from https, site breaks and we get error.

 

 

But when same irule is configured only on http virtual server, then we can go back and forth from http to https and then back to http without any issue. But the problem is we only get client ip on weblogic access log for http request only. For https request we get f5 ip.

 

 

I am guessing I am missing some minor details. I checked around for similar solution but couldn't see any. Can you guys point me to right direction?

 

 

Any help will be much appreciated.

 

 

Thanks,

 

 

2 Replies

  • when we try to come back to http://mywebsite.com from https, site breaks and we get error.what is the error about? i think the error may not relate to the irule because what the irule does is just to add http header. is there any other reason you may think of? anyway, i am not familiar with weblogic, so i might be wrong.

     

     

    just my 2 cents.
  • Having poured through some searches on the subject, I would definitely agree with Nitass. There must be something in the application logic that is causing the break. I would highly recommend having a look at both the client side traffic (via something like HTTPWatch or Fiddler in the browser) and the server logs to see if there's something about the WL-Proxy-Client-IP header that the HTTP site doesn't like after returning from the HTTPS site.