Proxy system streamlines Web requests

Web-resource mapping dynamically rewrites URLs so IT managers don’t need to alter applications to work outside their firewalls.

Proxies have been longtime friends and foes of Web servers. On one hand, proxies offer protection, caching, Secure Sockets Layer acceleration, compression and authentication. The downside, though, is that many Web sites and applications don’t work with proxies.

Web-resource mapping, a new technology embedded in SSL VPN proxies, dynamically rewrites URLs so IT managers don’t need to alter applications to work outside their firewalls.

The proxy problem

When a Web site sends a page to a user, it typically includes a variety of embedded references to other objects on the site. If the references are relative, meaning that they don’t include the name of the server within them (/content.html) rather than absolute (https://www.example.com/content.html), there is no problem. However, most Web sites do embed absolute links.

Two problems arise. The first frequently occurs in situations where a proxy also is performing SSL acceleration. When links embedded in the document are prefixed with “http” instead of “https,” users’ clicks are made to the unencrypted pages where URLs are sometimes delivered without question or just don’t work.

The second problem occurs when a proxy’s domain name is different from the server’s name – for example, a server named server.example.com and a proxy called www.example.com. Applications that look to the host name might end up embedding links such as https://server.example.com/content.html when they should say https://www.example.com/content.html.

The presence of JavaScript and HTTP cookies often exacerbates the problem. JavaScript-driven pages often dynamically assemble URLs on the client side, and the HTTP cookies are sent from the server such that the client will only send them back when communicating with the server and not through a proxy.

In most cases, site administrators lack the time, money and resources to make the significant and necessary changes to applications to fix a problem. Instead, what is needed is a mapping of incorrect URLs to the correct form. The mapping has to happen for links being sent from the server to the client and for HTTP requests from the client to the server.

Web-resource mapping dynamically rewrites URLs embedded within HTML, DHTML, XHTML, Cascading Style Sheets, JavaScript, HTTP cookies and Flash. This causes links that once appeared as https://intranet.company.com/content.html to now appear as https://proxy.company.com/prx/000/http/intranet.company.com/content.html.

While this might seem to be a simple case of “search and replace,” it is a more complex task because HTML standards are rarely followed and JavaScript cannot be altered in an ad hoc manner. JavaScript in particular poses great challenges because the code must remain syntactically and semantically correct.

Another key role of Web-resource mapping is to force SSL onto applications that could not otherwise support it, or do so in an incomplete manner. This is accomplished by rewriting each link so that it must use SSL for all transactions, such as starting all links with “https” instead of “http.”

Ideally, Web-resource mapping is performed inside the proxy server sitting between a client and server. The proxy simply can sit in front of application and Web servers and transmit their requests. When the proxy receives an HTTP request, it parses the modified URL, rewrites it to agree with what the origin server expects and finally passes it back to the server so the server doesn’t realize that the content was modified in any way.

IT departments supporting applications that go through a proxy performing Web-resource mapping benefit from centralized authentication, authorization and accounting. Regardless of which server sends the content, all requests for content go back through the proxy. And if the proxy is using SSL for all the links, the data flow is guaranteed to be secured.

Shah is director of product management at Array Networks. He can be reached at sshah@arraynetworks.net.