The FOXY System

This section demonstrates the server's functionality on the basis of a common connection scenario. We give a short description of some functional important classes and how they act together during the connection- and filtering-process. More detailed information about the mentioned Java-classes and packages can be found in section 2.3.2.

Figure 2.1 illustrates the stakeholders involved and the actions that have to be done, whenever a client user-agent requests a web page through the proxy server.

**Figure 2.1:** Overview of FOXY

In the first step (1), the client sends an HTTP-request to the proxy server. An HTTP-request generally consists of one (text-)line containing the request's method (e.g. GET, HEAD, POST) and its URI, as well as an HTTP-header, which contains one or more key-value pairs, called HTTP-header fields (see figure 2.2).

**Figure 2.2:** HTTP-request message format
$\begin{figure} \begin{small} \begin{verbatim} <METHOD> <request-uri> <HTTP-V... ...field1> <Headerfield2>: ... ...\end{verbatim} \end{small} \end{figure}$

A simple HTTP/1.1-request (to ''http://www.xyz.com/'') is shown in figure 2.3 (Note: Header field ''Host'' is mandatory in HTTP/1.1):

**Figure 2.3:** Common HTTP (1.1) request
$\begin{figure} \begin{small} \begin{verbatim} GET / HTTP/1.1 Host: www.xyz.com\end{verbatim} \end{small} \end{figure}$

When a client connects through a proxy server, however, it sends the full URI to the proxy (because it needs the server's address), which is then responsible for a correct forwarding of a ''proper'' HTTP-request (see figure 2.4)

**Figure 2.4:** HTTP (1.1) request through a proxy server
$\begin{figure} \begin{small} \begin{verbatim} GET http://www.xyz.com/ HTTP/1.1 Host: www.xyz.com\end{verbatim} \end{small} \end{figure}$

In the next step (2), the server looks for a pattern that may match the client's request. A pattern is unique for every host (and port) and can include several ''sub-patterns'' for different paths on this host. To enlarge granularity and flexibility, pattern-definitions may also contain simple conditional expressions (see section 2.4.2). When the incoming request has matched a particular pattern, the PatternMatcher-component delivers back a set of transformation-rules (3). Additionally, the pattern may also include instructions for modifying the HTTP-request forwarded to the original server This is mostly needed if the client asks for content, the web server cannot deliver. In this case, we have to change the ''Content-Type''-header field to an appropriate value before delegating the request to the web server (4). All other transformations (except the redirection of requests, naturally) are done after the HTTP-server has sent back the requested content to the proxy server (5). This task involves the appliance of one or more XSL- or XQuery-stylesheets, simple search-and-replace operations or the splitting (or re-layouting) of pages. These transformation-rules may also be summarized in so-called groups. In the last step (6), the proxy server returns the transformed response-data - which may include modified header fields - back to the client,

The different types of transformations (or -rules, respectively) (I-IV) are explained in detail in the configuration-section (see section 2.4.2 and 2.4.3.

root 2006-05-22