Forum Discussion

M_Links_with_N_'s avatar
M_Links_with_N_
Icon for Nimbostratus rankNimbostratus
Aug 28, 2015

Connection Reset When Redirecting From HTTPS to HTTP

I have a virtual server performing client SSL offloading for https://www.xyz.com and its URIs. A separate virtual server is configured for apps listening on port 80.

Requests to https://www.xyz.com/test are required to be redirected to port 80. The iRule below is applied to the 443 vs to satisfy the requirement:

when HTTP_REQUEST { 

set hostname [string tolower [HTTP::host]]
set subdir [string tolower [HTTP::uri]]

if { ($subdir contains "/test") } {
HTTP::redirect "http://$hostname$subdir"
}
}

All 443 hits to "/test" result in connection resets. I've confirmed the 80 vs is responding as expected to HTTP "/test" requests and have reached out to the application owner regarding possible changes on their end, as the above solution was working earlier this week and I have not made changes to the aforementioned virtual servers.

Thank You.

4 Replies

  • Ultimately I think you should do a client side capture with a tool like Fiddler or HTTPWatch. If you're certain that a direct request to http://www.xyz.com/test works, then try it through the HTTPS VIP with the capture. Do you actually see a 302 redirect to http://www.xyz.com/test?

    You can also simplify your iRule:

    when HTTP_REQUEST {
        if { [string tolower [HTTP::uri]] starts_with "/test" } {
            HTTP::redirect "http://[HTTP::host][HTTP::uri]"
        }
    }
    
    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      504 suggests the connection to your VIP is timing out and fiddler is returning the 504 since fiddler is proxying the connection. Are you sure the traffic is hitting your VIP? No firewall in the way. Also, can you confirm you have an http profile attached to your https vip?
  • I neglected to mention the 443 virtual server has two iRules applied:

    http_redirect_www.xyz.com_test (redirects 443 requests to 80)

    insert_https_offloaded_header (adds x-forwarded-proto info to packet headers)

    The order in which irules are listed on virtual server profiles dictates the order in which they’re executed. In this case, the above order results in error because the LTM is attempting to add the "'X-Forwarded-Proto'" information to packet headers after redirecting the client. Rather than allow traffic to proceed without modifying header information, the LTM resets the connection.

    Reversing the order fixes the issue.

    Support discovered the following entries in /var/log/ltm , which hinted the "insert_https_offloaded_header" iRule was somehow involved:

    Sep  1 11:29:40 xyz-f5-ltm err tmm[12022]: 01220001:3: TCL error: /Common/insert_https_offloaded_header <HTTP_REQUEST> - Operation not supported (line 1) invoked from within "HTTP::header insert "X-Forwarded-Proto" "https""
    Sep  1 11:29:40 xyz-f5-ltm err tmm[12022]: 01220001:3: TCL error: /Common/insert_https_offloaded_header <HTTP_REQUEST> - Operation not supported (line 1) invoked from within "HTTP::header insert "X-Forwarded-Proto" "https""
    Sep  1 11:29:45 xyz-f5-ltm err tmm[12022]: 01220001:3: TCL error: /Common/insert_https_offloaded_header <HTTP_REQUEST> - Operation not supported (line 1) invoked from within "HTTP::header insert "X-Forwarded-Proto" "https""
    

    Thanks for your help.