Forum Discussion

Jon_46029's avatar
Jon_46029
Icon for Nimbostratus rankNimbostratus
Aug 11, 2011

Odd handling of a redirect?

Background

 

 

BIG-IP 9.4.8 Build 355.0 Final

 

 

This is an SSL termination config. The virtual server at https:// resolves correctly to http://:7003 (single node in the pool).

 

 

No iRules configured

 

 

An http-wan-optimized-compress-caching profile (Parent) profile with all default settings except "Redirect Rewrite" set to "All" (same result if I use "Matching")

 

 

Symptom

 

 

A link on the resulting page sends me to https://:80 which fails as expected. I've not run across this behavior before (51 virtual servers on this LTM alone). Have I just been lucky? I don't have a long history with the BigIP LTM.

 

 

Setting Redirect Rewrite to "None" sends to http:// (no SSL).

 

 

The javascript behind the page link says "window.open('/path',_self);"

 

 

Jon

 

4 Replies

  • Hi Jon,

     

     

    Is the issue with a 30x redirect or a Javascript call? Can you use Fiddler2 or HttpFox to trace this and post the response headers or payload where the issue occurs?

     

     

    Aaron
  • Thanks for the reply, Aaron. I was OOO last week.

     

     

    Today I am able to pursue this matter again and I see ... the link is working properly. I am unaware of any changes made in my absence.

     

     

    Now I am dealing with another URL that performs a 302 temporary redirect and the BigIP is inserting an HTTPS url (this is not a SSL connection at the BigIP for this application). What do you suspect?

     

     

    Thanks,

     

    Jon

     

     

     

     

  • I have marked this RESOLVED.

     

     

    After reading http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/220/Rewriting-Redirects.aspx I have set the Redirect Rewrite to "None" and all is working on the latest issue.

     

     

    Thanks, Jon
  • Had to reopen this... When I marked it resolved I was looking at a different LTM and environment... At least that mystery is gone 🙂

    here are the rows from HttpFox.

    00:00:18.0830.177683174GET302Redirect to: https://.com:80/path/https://.com/path
    00:00:18.3001.0546870GET(Error)NS_ERROR_CONNECTION_REFUSEDhttps://.com:80/path/