The user enters a URL or clicks on a link. This creates a connection followed by a request from the browser to the web server. As part of the HTTP protocol the browser identifies in its request header whether it is capable of receiving compressed content as well as the manner of acceleration it understands.
As IIS receives the request, it gives all hooked programs (including jetNEXUS) a chance to look at the incoming request. jetNEXUS uses this data to determine the browser's ability to receive compressed content and,based on browser type and version,the extent to which it can accept accelerated content.
For example, Netscape Navigator version 4.x browsers can only process accelerated body content and cannot handle compressed CSS style sheets. MS Internet Explorer version 5.x browsers, on the other hand, can process both types of content in compressed format.
IIS then processes the request and generates the appropriate response. However, before sending this response to the requesting browser, IIS once again gives each hooked program in turn a chance to see and modify the response.
jetNEXUS examines the response header(s) and determines whether the output is of a compressible type. If the output is not of a type that jetNEXUS can compress (e.g. GIF, JPEG, etc.), it simply stays out of the way. However, if the output is a compressible type AND jetNEXUS knows from the request that the browser can accept compression, jetNEXUS modifies the response. The content of the response is accelerated and the response headers are modified to show this and the revised length of data.
IIS then completes the process by passing the response back to the browser. From the end user's point of view this whole process is transparent, apart from the fact that the page arrives much, much faster! |
