Rewrite http:// to https:// in response content
Problem this snippet solves: (Maybe I missed it, but) I didn't see a code share for using a STREAM profile to rewrite content from http to https. This share is just to make it easier to find a simple iRule to replace http:// links in page content to https://. It's taken directly from the STREAM::expression Wiki page. How to use this snippet: You'll need to assign a STREAM profile to you virtual server in order for this to work (just create an empty stream profile and assign it). Code : # 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 } } Tested this on version: 11.5
LineRate HTTP to HTTPS redirect
Here's a quick LineRate proxy code snippet to convert an HTTP request to a HTTPS request using the embedded Node.js engine. The relevant parts of the LineRate proxy config are below, as well. By modifying the redirect_domain variable, you can redirect HTTP to HTTPS as well as doing a non-www to a www redirect. For example, you can redirect a request for http://example.com to https://www.example.com . The original URI is simply appended to the redirected request, so a request for http://example.com/page1.html will be redirected to https://www.example.com/page1.html . This example uses the self-signed SSL certificate that is included in the LineRate distribution. This is fine for testing, but make sure to create a new SSL profile with your site certificate and key when going to production. As always, the scripting docs can be found here. redirect.js: Put this script in the default scripts directory - /home/linerate/data/scripting/proxy/ and update the redirect_domain and redirect_type variables for your environment. "use strict"; var vsm = require('lrs/virtualServerModule'); // domain name to which to redirect var redirect_domain = 'www.example.com'; // type of redirect. 301 = temporary, 302 = permanent var redirect_type = 302; vsm.on('exist', 'vs_example.com', function(vs) { console.log('Redirect script installed on Virtual Server: ' + vs.id); vs.on('request', function(servReq, servResp, cliReq) { servResp.writeHead(redirect_type, { 'Location': 'https://' + redirect_domain + servReq.url }); servResp.end(); }); }); LineRate config: real-server rs1 ip address 10.1.2.100 80 admin-status online ! virtual-ip vip_example.com ip address 192.0.2.1 80 admin-status online ! virtual-ip vip_example.com_https ip address 192.0.2.1 443 attach ssl profile self-signed admin-status online ! virtual-server vs_example.com attach virtual-ip vip_example.com default attach real-server rs1 ! virtual-server vs_example.com_https attach virtual-ip vip_example.com_https default attach real-server rs1 ! script redirect source file "proxy/redirect.js" admin-status online Example: user@m1:~/ > curl -L -k -D - http://example.com/test HTTP/1.1 302 Found Location: https://www.example.com/test Date: Wed, 03-Sep-2014 16:39:53 GMT Transfer-Encoding: chunked HTTP/1.1 200 OK Content-Type: text/plain Date: Wed, 03-Sep-2014 16:39:53 GMT Transfer-Encoding: chunked hello world
HTTP is fast, HTTPS really slow and causes massive FCS failure
I have two BIGIP VE's on my laptop I use for lab and education. On both of them (not HA) HTTPS to a VS works, but is painfully slow. A simple web page with a few pictures in it takes 20-30 seconds to load. Unencrypted HTTP is lightning fast. Here is the VS config: ltm virtual /Common/f5trn.cmos.lab-p443-vs { destination /Common/10.1.10.20:443 ip-protocol tcp mask 255.255.255.255 pool /Common/f5trn.cmos.lab-pool profiles { /Common/f5trn.cmos.lab { context clientside } /Common/http { } /Common/http2 { } /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } ltm pool /Common/f5trn.cmos.lab-pool { members { /Common/10.1.20.11:80 { address 10.1.20.11 } /Common/10.1.20.12:80 { address 10.1.20.12 } /Common/10.1.20.13:80 { address 10.1.20.13 } } monitor /Common/http } A packet capture shows a MASSIVE FCS failure. Every single frame. Same on both sides of the BIGIP. Troubleshooting includes: Disabling SSL (removing clientSSL profile). Not slow. Disabling HTTP/2 profile, using HTTP/1.1 (with SSL) instead. Still slow. Using normal clientssl profile. Still slow. Trying another BIGIP VE on the same laptop (standalone). Still slow. Upgrading virtual hardware from v7 to v12. Still slow. Upgrading memory on BIGIP VE 6 > 8 GB RAM. Still slow. CPU load is around 9% Memory usage is >80% high according to the flash-based dashboard. 6 or 8 GB RAM makes no difference. However TMM uses 5.5% of 3.9 GB. The Configuration Utility uses HTTPS and is very responsive. Other info: LTM, APM and AVR are provisioned The FQDN is resolved via /etc/hosts file BIGIP version is 13.1 My laptop is a MacBook Pro with core i7 with 16GB RAM and not slow or heavily loaded with anything else. Any ideas to why SSL seems to cause this behaviour?
Mobile browsers broken - https redirect
BigIP 1600's - v11.6 HF 4 I have a simple iRule that forces https and strips the www. We have a CMS running that automatically detects the user agent, and redirects the mobile browser to the mobile version of the website. As soon as I applied the following iRule, mobile browsers appeared to be broken upon the first initial page load request. With mobile Safari on iOS, (as well as Android) I get the following message when I browse the site: "Safari cannot open the page because it could not load any data" If I refresh the page a 2nd time, the mobile version of the website loads. What would be the best way to troubleshoot this? Would I need to implement logging to capture the user agent, and where the client is trying to go? Why would a refresh cause the page to load on the 2nd attempt? Here's the iRule: when HTTP_REQUEST { if {([string tolower [HTTP::host]] starts_with "www.")} { HTTP::redirect "https://[string range [HTTP::host] 4 end][HTTP::uri]" return } elseif { [TCP::local_port] == 80 } { HTTP::redirect https://[HTTP::host][HTTP::uri] return } }
Redirect TCP connections from port 443 to 80
Hi All We have a port 80 and 443 VIP configured for 301 redirections to send sites to specific pages on a target branding site. We use 301 redirects and it works just fine via irule. However, for this to work for HTTPS requests, we need a cert and SSL profile to decrypt the request and then redirect it. The same irule is in use for both the 80 and 443 VIPs I'm wondering whether it's possible to do a basic 'when client_accept/connect' irule to force ALL connections to the VIP to go to the port 80 version so that we don't need to keep purchasing certs for 'old' websites. Perhaps another option would be to set a single client_ssl profile on the 443 VIP, use a 'when clientssl_handshake' iRule and try redirect to 80 that way, but I have my doubts. This is a bit beyond my current iRule skills.... Cheershttps connection with URI shows as not secured ?
Hi Team , We have a new VIP with url https://example.test.com , but when we try to access the url with uri it says "The information you're bout to submit is not secure " https://example.test.com >> WORKS https://example.test.com/sap/saml2/sp/acs/100 >> error : "The information you're bout to submit is not secure " Please advice .
