SharePoint Redirect To New Path Using Public Name

I'm trying to use the following code to redirect public traffic over a secure link (https://) to a SharePoint 2013 server that's listening on port "33230" at "/sites/BI/".

if you want to rewrite uri, you should use HTTP::uri rather than HTTP::redirect.

Redirects, Rewrites and App Transfers via iRules by Colin Walker (Invisible Rewrite section)

Hi Brian, I'm a bit confused. The SharePoint web app is listening on port 33230, but I don't see port 33230 in your switch statement or redirect location.

I'm not sure that if statements nested inside switch statements work very well. Also, it's true that HTTP::uri will change the URI before it's sent to the server, but the browser doesn't get informed of that, which can cause issues. You could use HTTP::respond in this way to accomplish the same:

when HTTP_REQUEST  {
    if { [string tolower [HTTP::host]] contains "dashboards.domain.com" && [HTTP::uri] equals "/" }  {
        HTTP::respond 302 Location "https://dashboards.domain.com:33230/sites/BI"
    }
}

I'm curious about what happens when you point dashboards.domain.com at one of your server IPs, rather than the virtual server. Same result?

Mike

The port number is usually not going to be included in HTTP::host for 80/443 requests. And, if this virtual server is using a client SSL profile, then your redirect based on the port 80 case will never get triggered.

You'll need to create a virtual server at port 80 using the same IP address, and apply the _sys_https_redirect iRule to it. That will redirect all http:// unencrypted connections to your SSL virtual server, which should have something similar to the rule I posted above attached to it.

IIRC, HTTP::redirect is basically the same as "HTTP::respond 302 Location: ". HTTP::respond gives you more control if you want to include other headers, cookies, etc with your response.

I am not sure that using the custom port number for your pool members will work, because SharePoint is expecting a certain URL scheme for requests to a particular zone. Ports 443 and 33230 would need to have their own zones in Alternate Access Mappings. I have never tried that...you may want to experiment a bit with that.

Thinking more about it, in AAMs you should be able to set your public URL to https://dashboards.domain.com, and add an internal URL for https://dashboards.domain.com:33230. That's essentially what we do when SSL offloading.