Forum Discussion

MattB_MA_170307's avatar
MattB_MA_170307
Icon for Nimbostratus rankNimbostratus
Feb 10, 2016

HTTP to HTTPS stream correction

I have an application in Apache Tomcat that is hosted on an internal server on port 8080. Sitting in front of that is my BIP 2000 with a vserver performing SSL offload, also listening port 8080. In front of that I have a firewall NATing with port translation from 18080 to my vserver. The application on the host keeps making requests to http, which I know is a common problem, so I went to do a simple redirect to https, then I realized, it's calling http on the same port that https is running. This isn't the same as a simple redirect from 80 to 443, so then I tried this:

     Example which replaces http:// with https:// in response content
 Prevents server compression in responses
when HTTP_REQUEST {

    Disable the stream filter for all requests
   STREAM::disable

    LTM does not uncompress response content, so if the server has compression enabled
    and it cannot be disabled on the server, we can prevent the server from 
    sending a compressed response by removing the compression offerings from the client
   HTTP::header remove "Accept-Encoding"
}
when HTTP_RESPONSE {

    Check if response type is text
   if {[HTTP::header value Content-Type] contains "text"}{

       Replace http:// with https://
      STREAM::expression {@http://@https://@}

       Enable the stream filter for this response only
      STREAM::enable
   }
}

Which I really thought would work, but it didn't. HTTP calls are still getting through to the browser. What am I missing?

9 Replies

  • Does the firewall accept 443 from the clients, and translate to 8080? Or does the client need to send to port 8080?
  • The client hits our firewall on 18080, ie. https://myserver.com:18080/Application The firwall NATs the port to 8080, which is where the F5 has a vserver. The pool member is also listening on 8080. Now, the monkeywrench. If I SSL offload with nginx, there's no problems at all.
  • What I think you're saying is that the client is receiving links for HTTP content, when it should be seeing nothing but HTTPS links. Correct? If so, I'd fire up a client side capture app like HTTPWatch or Fiddler and see which URLs aren't getting rewritten.

     

  • The urls are completely being re-written, hence my attempt to catch the call for an http:// in the tcp stream and replace it with problem is that it's not working

     

    I may be missing something, but what you originally described indicates that you are likely NOT rewriting all of the URLs. If the browser is attempting to make http:// calls back to the server, it's getting that information from somewhere... The purpose of the client side capture is to determine the exact point in which the browser is doing that, where it's trying to go, and subsequently which previous response gave it that information.

     

  • So, is the case different than what you're searching for? Does the Content-Type of the page that returns this bad URL contain the word "text"?

     

  • Hmmm come to think of it, I dont think 302 redirects have a text header. And for case, that might be the problem. I'll give it a shot and let you know!

     

  • when HTTP_REQUEST { 
         Disable the stream filter for all requests
        STREAM::disable
    
         LTM does not uncompress response content, so if the server has compression enabled
         and it cannot be disabled on the server, we can prevent the server from 
         sending a compressed response by removing the compression offerings from the client
        HTTP::header remove "Accept-Encoding"
    }
    when HTTP_RESPONSE {
        if { [HTTP::header exists Location] } {
            HTTP::header replace Location [string map -nocase {"http://" "https://"} [HTTP::header Location]]
        }
         Check if response type is text
        if {[HTTP::header value Content-Type] contains "text"}{
             Replace http:// with https://
            STREAM::expression {@http://@https://@}
             Enable the stream filter for this response only
            STREAM::enable
        }
    }
    
  • Artur_Zdolinsk1's avatar
    Artur_Zdolinsk1
    Historic F5 Account

    This iRule can cause with some application problems with loading images like PNG which contains inside content data HTTP string. To prevent problems with missing images - you should ensure that on the beginning of HTTP_RESPONSE you first disable STREAM profile and then enable it only for text content-type. iRule should look like this:

    Exemple:

    when HTTP_REQUEST {
        STREAM::disable
        HTTP::header remove "Accept-Encoding"
    }
    when HTTP_RESPONSE {
        STREAM::disable
        if { [HTTP::header exists Location] } {
            HTTP::header replace Location [string map -nocase {"http://" "https://"}    [HTTP::header Location]]
        }
        if {[HTTP::header value Content-Type] contains "text"}{
            STREAM::expression {@http://@https://@}
            STREAM::enable
       }
    }
    }
    
    • Neil_66348's avatar
      Neil_66348
      Icon for Nimbostratus rankNimbostratus

      "Artur Zdolinski" you are an absolute legend!!!

       

      I was missing the STREAM::disable statement beneath the HTTP_RESPONSE and thus many images on our site were not loader properly (missing content-length headers etc). Adding this statement instantly fixed it. Thank you so much for sharing this

       

      :)