Overview

Increasingly, our modern-day workforce requires upward-mobility. It follows that a businesses infrastructure requirements are radically changing to suit their employees' needs. Zeus' Extensible Traffic Manager was designed to co-exist in a mobile environment; sustaining, securing and accelerating the infrastructure a work-force requires to reliably conduct business day-to-day.

Infrastructure software widely deployed to assist with a business' work-mobility is Microsoft's Outlook Web Access.

Integration with ZXTM

Outlook Web Access can be quickly, easily and securely integrated into ZXTM. We recommend that you allow ZXTM to handle the SSL decryption; reducing the cpu stress to your Exchange back-end(s). A HTTP
protocol server, listening on port 443, should be setup to handle traffic to your Exchange server. ZXTM will now take care of the rest!

WebDAV Conformity, Exchange and SSL Decryption

Zeus has discovered a requirement to implement a trafficscript solution in situations where a non-standard WebDAV resource is invoked. RFC2518 states that:

There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names.

In certain circumstances, a client will issue a request for /exchange instead of /exchange/. As per the RFC, a webserver will correctly respond by issuing a 301 object permanently moved header.

Let us confirm this by using httpclient.

root@zahn# ./httpclient -m HEAD http://www.zeus.com/about
HTTP/1.1 301 Moved Permanently
Vary: Accept-Encoding
Connection: close
Content-Length: 212
Date: Sun, 23 Jul 2006 03:51:38 GMT
Location: http://www.zeus.com/about/

A client request complete with a trailing slash meets with a different server response code:

root@zahn# ./httpclient -m HEAD http://www.zeus.com/about/
HTTP/1.1 200 OK

In normal circumstances, a client receiving a http 301/302 status code would transparently obey the instruction and a correct GET request issued, complete with trailing slash. With ZXTM performing its magic and taking care of all SSL transactions, a back-end Exchange server is now only HTTP aware. As a consequence, the re-direct issued by Microsoft IIS will be a HTTP based URI. IIS is acting perfectly correctly, but unfortunately the request by the client will not succeed as an Exchange server is often only configured for secure (HTTPS) connections.

To confirm this, let's make a HTTP request to a secure site with ZXTM in front, performing SSL-decryption, but without a trailing slash. If what we have talked about above is correct, we will see a Location: banner for a (non-secure) HTTP re-direct.

root@zahn:# ./httpclient -m HEAD -3 https://www.zeus.com/internal-test
HTTP/1.1 301 Moved Permanently
Content-Length: 212
Date: Sun, 23 Jul 2006 04:05:11 GMT
Connection: close
Location: http://www.zeus.com/internal-test/

So, our real-world test confirms the theory.

TrafficScript Provides a Solution

TrafficScript is a feature-rich scripting language, that presents a quick and easy solution to this problem.
The following response rule will inspect traffic, actioning a Location: header re-write on 301 or a 302 status code.

$status = http.getResponseCode();
if (($status == 301) || ($status == 302)) {
        $location = http.getResponseHeader("Location");
        $new_location = string.regexsub ($location, "http://(.*?)(/.*)",
"https://$1$2");
        http.setResponseHeader("Location", $new_location);
}

Now, with this rule enabled, let's perform our previous test:

root@zahn:# ./httpclient -m HEAD -3 https://www.zeus.com/internal-test
HTTP/1.1 301 Moved Permanently
Content-Length: 212
Date: Sun, 23 Jul 2006 04:10:53 GMT
Connection: close
Location: https://www.zeus.com/internal-test/

As you can observe, the Location header has successfully been re-written to re-direct the client to a HTTPS URI.

Trafficscript in place, you can now allow ZXTM to securely and reliably interact with Microsoft Exchange, working to deliver a first-class mobile business solution for your customers.

Chris Buckley [Zeus Support] 23 July 2006