server is wrongly returning unencrypted url as part of an SSL connection

[axfalk]

  WWe're running ACE SM 5.2 and are seeing an anomaly, where when a client sends encrypted traffic to the ACE in an SSL termination configuration, the ACACE terminates the SSL traffic and then sends clear text to the server. Because the server is unaware of the encrypted traffic flowing between the client and the ACE, the server is returning to the client the unencrypted URL as opposed to the encrypted one. As we have quite a few of these encrypted URLs where the ACE is doing the SSL termination, and pretty much all of them are working OK, what determines whether the server returns an encrypted or unencrypted URL?

Thanks.

[Steven Doremus]

When you instruct the ACE to insert SSL session information, by default, the ACE inserts the HTTP header information into only the first HTTP request that it receives over the client connection. When the ACE and client need to renegotiate their connection, the ACE updates the HTTP header information that it sends to the server to reflect the new session parameters. You can also instruct the ACE to insert the session information into every HTTP request that it receives over the connection by creating an HTTP parameter map with either the header modify per-request or persistence-rebalance command enabled. 

Refer to the following Cisco document @http://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/ssl/guide/sslgd/terminat.html#wp1169219

[Steven Doremus]

solve this problem, the ACE provides SSLURL rewrite, which changes the redirect URL from http:// to https:// in the Location response header from the server before sending the response to the client. By using URL rewrite, you can avoid nonsecure HTTP redirects. All client connections to the web server will be SSL, ensuring the secure delivery of HTTPS content back to the client. The ACE uses regular expression matching to determine whether the URL needs rewriting. If a Location response header matches the specified regular expression, the ACE rewrites the URL. In addition, the ACE provides parameters to add or change the SSL and the clear port numbers.

[axfalk]

Thanks for your reply. I understand the mechanism that is used for fixing the anomalous HTTP redirection from the server back to the client. My question is why does it happen in the first place. We have many HTTPS connections to the ACE that are correctly being returned from the servers back to the client as HTTPS. But then we have some that are being returned as HTTP - I was wondering if someone could pls explain what would make the servers do this.

Thanks.