Forum Discussion

Scott_H's avatar
Scott_H
Icon for Nimbostratus rankNimbostratus
Oct 15, 2014

https:// getting redirected to http://xxx:443

Hi all- At my wit's end, we have an app that does all their own redirects via IIS rewriter module. We insert the 'protocol' of the request via an iRule that inserts a custom http header 'protocol' with a value of [TCP::local_port clientside] from the 'CLIENT_ACCEPTED' event. If the protocol is '80' they redirect to https. That works fine. In a network trace, I seen the request then come in as https://foo.bar.com. with protocol '443'. Still all good.

 

Here's where it get's funky, the server then 301 redirects to 'http://foo.bar.com:443' which causes a 503. They swear up and down the server/rewriter is working fine and I do the same for the LTM. Does anyone have any ideas, or have seen this behavior before? Is there any way the LTM would be interpreting https:// as http://:443? This same iRule works fine lots of other places for the same app so I don't think it's the iRule/syntax, etc. Network traces seem to show the server causing the issue, just want to make sure I'm covering my bases. This is a very difficult thing to google. Thanks!

 

application delivery
availability
devops
iRules
LTM
TMOS

2 Replies

Sort By
  • Arnaud_Lemaire's avatar
    Arnaud_Lemaire
    Icon for Employee rankEmployee
    Oct 15, 2014

    You should log the server response. If i understand your irule is just playing with the port and not the schema so maybe the server is not redirecting to https for 301.

     

  • Scott_H's avatar
    Scott_H
    Icon for Nimbostratus rankNimbostratus
    Nov 13, 2015

    I see some others have viewed this question, thought I'd post what our fix was although we never completely determined what was causing the issue. A change was made in the IIS rewriter to deal with a request that came in with the http://foo.bar.com:443 format so that it did not return the 503 error. Also, we turned off redirect caching in the AAM/WebAccel policy. As far as we could tell there was some condition that caused the IIS rewriter to very rarely return the bad redirect, and then the issue was amplified by AAM caching that redirect.