WO2008039117A1

WO2008039117A1 - A method and apparatus for controlling a proxy server

Info

Publication number: WO2008039117A1
Application number: PCT/SE2006/001102
Authority: WO
Inventors: Thorsten Herber; Magnus Thulstrup
Original assignee: Telefonaktiebolget Lm Ericsson (Publ)
Priority date: 2006-09-29
Filing date: 2006-09-29
Publication date: 2008-04-03
Also published as: GB0907111D0; GB2456255B; GB2456255A

Abstract

A method and arrangement in a proxy server (200) for adapting and controlling communication between client terminals (T) and web servers (S) over the Internet or an Intranet. A plurality of workflow scripts (206) and a plurality of script-controlled function modules (208) are implemented in the proxy server. The function modules are associated with said workflow scripts, for performing specific functions of the proxy server when handling received client requests directed to web servers. Each function module is adapted to perform a specific function based on instructions from an associated workflow script.

Description

A METHOD AND APPARATUS FOR CONTROLLING A PROXY SERVER

TECHNICAL FIELD

The present invention relates generally to a method and apparatus for providing a proxy server connected to one or more access networks to support communication with web servers over the Internet or an Intranet. In particular, a solution is provided for facilitating modifications and adaptations in a proxy server.

BACKGROUND

The advent of Internet has created a vast industry for making all kinds of information and data available to any user operating a communication terminal equipped with a web browser. Many so-called host servers or web servers offer any kind of information and services over the Internet as available from web sites. A user, typically referred to as a "client", can then access wanted information or services by sending a request to a server hosting a particular web site, e.g. for fetching a web page or a software program available from the web site. The contacted server then sends some kind of response back to the requesting client.

The communication protocol HTTP (HyperText Transfer Protocol) is generally used for transferring web pages between a web server, or "HTTP server", and a web browser residing in the client's terminal. In order to allow mobile terminals to access wireless services, the protocol called WAP (Wireless Application Protocol) is used which is a specification designed to adapt Internet content for viewing from a mobile terminal display. In order to support and control the communication between clients and web servers on the Internet, intermediary proxy servers are used which are basically- adapted to communicate with external web servers on behalf of clients, and vice versa. In the following description, the term "proxy server" is used for short to represent a HTTP proxy server and/or a WAP proxy server. Even though the Internet is used throughout in the following examples, an Intranet may also be equally applicable for the described communications between clients and web servers.

A proxy server is basically a computer offering a computer network service to allow clients to make indirect network connections to other network services. The proxy server generally adapts and controls the communication between the clients and web servers, providing suitable interfaces on one side towards the servers and on the other side towards the clients. A client first connects to the proxy server, then requests a connection, file, or other resource available on a web server. The proxy server is adapted to provide the requested resource either by connecting to the specified web server or by retrieving it from a cache. In some cases, the proxy may alter the client's request or the server's response for various purposes, e.g. depending on prevailing policies and rules. A typical proxy application often provides a nearby cache of web pages and files originally available on remote web servers, allowing clients to access them more quickly or reliably. When receiving a request for a particular web resource (specified by a URL) , a caching proxy looks for the given URL in its local cache. If found, the requested web resource can be retrieved from the cache and delivered immediately. Otherwise it fetches the resource from the .remote server, returns it to the requester and optionally also saves a copy in the cache.

Fig. 1 illustrates a typical communication scenario where a mobile client terminal T accesses a web server S amongst a plurality of web servers 100 over the Internet 102 using a conventional proxy server 104, according to the prior art. The terminal T is connected to a mobile access network 106, which in this case is based on GPRS (General Packet Radio Service) and/or WCDMA (Wideband Code Division Multiple Access) technology using a gateway node called GGSN (Gateway GPRS Support Node) connected to the proxy server 104. Further access networks may also be connected to the same proxy server 104, as generally illustrated by the numeral 110. In more detail, the proxy server 104 is logically divided into different functional stack layers, including a server stack layer 112 facing the client side basically to receive requests from client terminals using WAP or HTTP, and a client stack layer 114 facing the web server side basically to send HTTP requests to the origin servers on the Internet. Thus, the server stack 112 and the client stack 114 are configured to adapt the communication to clients and web servers, respectively, such that server stack 112 basically appears as a web server towards client T and client stack 114 basically appears as a client towards web server S.

Furthermore, a hard-coded proxy layer 116 is arranged between the server stack 112 and the client stack 114 in the proxy server 104, being responsible for various controlling and supporting functions, such as: subscriber identification, access control, charging, statistics, content filtering, format conversion, etc. In order to execute such functions, the proxy layer 116 may exchange information with various external units schematically indicated by the numeral 118, to support these functions when needed, such as an online charging unit or a network access control unit. The proxy layer 116 may also retrieve various information from a session database 120 and a subscriber database 122, that may be required in order to control the communication and to support the proxy functions, e.g. as mentioned above. The server stack 112 and the client stack 114 in the proxy server 104 are well specified and not required to change very often. However, the functions implemented in the proxy layer 116 are typically very operator specific and changes or modifications of these functions may be required more or less frequently to keep them up-to-date with new services and policies. Moreover, a conventional proxy layer is hard-coded, making it quite expensive and difficult to make any changes or modifications to the functions in the proxy layer 116. Therefore, the entire proxy layer must be hard-coded anew when implementing a new or modified function, and each function modification or addition requires considerable knowledge of the design and implementation of the entire proxy layer code. There is also always a considerable risk that modification or addition of functions in the proxy layer 116 could unintentionally influence existing functions in a negative and/or unpredictable way.

Therefore, a solution is desirable for making modifications or changes of functions more easy and reliable. It is also generally desirable to obtain greater flexibility of such functions in a proxy server supporting communication between clients and web servers over the Internet or an Intranet.

SUMMARY It is an object of the present invention to generally avoid the problems outlined above and to provide a proxy server with reliable and flexible functionality, for supporting communication between clients and web servers over the Internet or an Intranet. These objects and others are obtained by providing a method and an arrangement in a proxy server for adapting and controlling communication between a client terminal and a web server over the Internet or an Intranet, as defined by the independent claims. In one aspect of the invention according to the inventive method, when a client request from the client terminal directed to the web server is received, a workflow script is selected in the proxy server for the request. The workflow script is adapted to give instructions to at least one associated script-controlled function module for performing a specific function of the proxy server when handling the client request. The selected workflow script is then executed for the received client request.

A plurality of different workflow scripts and associated function modules can be implemented in the proxy server as a proxy layer between a server stack layer facing client terminals and a client stack layer facing web servers. The workflow scripts are selected for different proxy functions, preferably as different types of workflow scripts including a session script, an incoming request script and an outgoing request script. The session script type basically specifies how the proxy server should operate when the client terminal starts or ends a web browsing session, and may also specify how the proxy server should validate that the network address of the terminal connected to the session is still allocated to the same terminal having started the session.

The incoming request script type basically specifies how the proxy server should operate when said client request is received from the client terminal, and when a response from the web server to that request is delivered to the client terminal.

The outgoing request script type basically specifies how the proxy server should operate when an outgoing request of the client terminal is sent to the web server, and when a response to that request is received from the web server.

The function modules may perform various proxy functions such as subscriber identification, access control, charging, statistics, content filtering, and format conversion. At least some of the function modules may be connected to external units and databases to support their functions.

If a response from the web server refers to one or more embedded objects and the client terminal supports multipart content, a multipart handler in the proxy server may be used to create a subsequent outgoing request to the web server for each embedded object, for delivery to the client in a single multipart response.

The workflow script may be selected based on at least one of: the type of client terminal or user-agent having sent the request, the identity of the web server, and the nature of the request and/or invoked service. A pre- processing script, designed to correct any errors or bugs that are known to generally occur in requests from specific terminal models, may be selected if available for the model of the requesting client terminal. The workflow script may then be selected based on a URL given in said client request, and/or based on the identity of the operator and/or network serving the requesting client. Otherwise, a default workflow script may be selected if no URL-specific and/or operator/network specific workflow script is available for the client request. The workflow script may further be selected based on any of: the current type of client subscription, the current time of day/week/season, and the current traffic load.

The selected script can be executed immediately if a valid version of the script is available in binary encoded form. However, if a valid version of the script is available only in textual form and not in binary encoded form, the textual version of the script is loaded and translated into a binary format before being executed. In another aspect of the invention, the inventive arrangement in the proxy server comprises a plurality of workflow scripts and a plurality of script-controlled function modules associated with said workflow scripts, for performing specific functions of the proxy server when handling received client requests directed to web servers. Each function module is adapted to perform a specific function based on instructions from an associated workflow script.

The workflow scripts and associated function modules can be implemented in the proxy server as a proxy layer between a server stack layer facing client terminals and a client stack layer facing web servers. The workflow scripts preferably include the following types of workflow scripts: session scripts, incoming request scripts and outgoing request scripts, each specifying how the proxy server should operate as described above for the inventive method.

The function modules can be adapted to perform different proxy functions, e.g., subscriber identification, access control, charging, statistics, content filtering, and format conversion. The proxy server arrangement may further comprise a multipart handler adapted to, if a web server response to a client request refers to one or more embedded objects and a requesting client terminal supports multipart content, create a subsequent outgoing request to the web server for each embedded object, for delivery to the client in a single multipart response.

The proxy server arrangement may further comprise means for selecting a workflow script for a particular client request directed to a web server, based on at least one of: the type of client terminal or user-agent having sent the request, the identity of the web server, and the nature of the request and/or invoked service.

The script selecting means may be adapted to select a pre-processing script, designed to correct any errors or bugs that are known to generally occur in requests from specific terminal models, if available for the model of the requesting client terminal. The script selecting means may further be adapted to select the workflow script based on a URL given in said client request. The script selecting means may further be adapted to select the workflow script based on the identity of the operator and/or network serving the requesting client. The script selecting means may further be adapted to select a default workflow script if no URL-specific and/or operator/network specific workflow script is available for the client request. The script selecting means may further be adapted to select the workflow script based on any of: the current type of client subscription, the current time of day/week/season, and the current traffic load.

The proxy server arrangement may further comprise means for executing the selected script immediately if a valid version of the script is available in binary encoded form, and means for loading and translating an available textual version of the selected script into a binary format before being executed, if no valid version of the script is available in binary encoded form.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail and with reference to the accompanying drawings, in which: - Fig. 1 is a block diagram illustrating a communication scenario where a client terminal accesses a web server over the Internet using a conventional proxy server, according to the prior art.

- Fig. 2 is a block diagram illustrating a communication scenario where a client terminal accesses a web server over the Internet using a proxy server, according to one embodiment .

- Fig. 3 a flow chart illustrating steps performed in a proxy server when handling an incoming request from a client, according to another embodiment. - Fig. 4 is a flow chart illustrating steps performed in a proxy server when handling an incoming response from a web server, according to yet another embodiment.

- Fig. 5 illustrates an exemplary architecture for implementing three types of workflow scripts and associated function modules in a script controlled proxy layer, according to yet another embodiment.

- Fig. 6 is a flow chart illustrating steps performed in a proxy server when selecting a workflow script, according to yet another embodiment.

- Fig. 7 is a flow chart illustrating steps performed in a proxy server when executing a selected workflow script, according to yet another embodiment.

DETAILED DESCRIPTION

A basic exemplary embodiment of the present invention will now be described with reference to a communication scenario illustrated in Fig. 2, involving an inventive proxy server 200. As similar to the situation shown in Fig. 1, a mobile client terminal T accesses a web server S via the proxy server 200 which is configured with a layered structure including a server stack layer 202 facing the client terminal T, and a client stack layer 204 facing the web server S. However, instead of using an intermediary hard-coded proxy layer, a set of workflow scripts 206 and associated function modules 208 are arranged between the server stack layer 202 and the client stack layer 204, making up the proxy layer. Even though a mobile terminal is illustrated in the following examples, is should be noted that the described solutions and embodiments are applicable for any kind of client terminal capable of acting as described below. Each workflow script 206 comprises a series of work instructions which, when executed, activates one or more specific proxy functions implemented in the associated function modules 208, e.g. the above-mentioned functions of subscriber identification, access control, charging, statistics, content filtering, format conversion, etc. The function modules 208 are thus script-controlled, or "scriptable". The workflow scripts 206 may be written according to the ECMA-262 standard, often referred to as ECMA script, Javascript or Jscript.

Certain function modules 208 may be further connected to various external units and databases to support their functions, exemplified in the figure by the numerals 210, 212 and 214. For example in Fig. 2, one module Mi may be adapted to perform subscriber identification and exchanges information with an external subscriber database 210. Another module M₃ may be adapted to perform charging control and exchanges information with an external charging unit 212, and yet another module M₄ may be adapted to perform access control and exchanges information with an external access control unit 214, and so forth. When the proxy server 200 receives a request from a client, or a response from a web server, one or more suitable workflow scripts are selected from the set of scripts 206, e.g. based on the nature of the request and/or service invoked. The process of script selection will be described in more detail later on in this description.

Fig. 3 is a flow chart illustrating some basic steps executed in the proxy layer of a proxy server when handling an incoming request from a client directed to a web server. Reference to Fig. 2 will also be made when describing the steps in Fig. 3 as follows. In a first step 300, an incoming client request directed to web server S is received from the server stack 202, having originally received the request from client terminal T. A suitable work script is selected from the set of scripts 206 for processing the client request, in a next step 302. The selected script is then executed in a following step 304, which may involve activation of one or more associated function modules 208 as described above. In a next step 306, it is determined whether another work script is required for processing the client request, e.g. depending on the nature of the request, the type of client terminal and/or the identity of the web server. If no further script is required, the request is forwarded to the client stack 204 in a final illustrated step 308, for transfer to the web server S. If it is determined in step 306 that another script is required for further processing the client request, the process moves back to the step 302 of selecting a script, and so forth. In this manner, steps 302-306 are repeated until no further script is required and step 308 can be finally executed. Fig. 4 is a flow chart illustrating some basic steps executed in the proxy layer when handling an incoming response from a web server, i.e. moving in the opposite direction through the proxy server 200. The server response is given in response to the client request handled in Fig. 3. Reference to Fig. 2 will again be made when describing the steps in Fig. 4 as follows.

In a first step 400, an incoming response directed to client terminal T is received from the client stack 204, being a response from server S to the earlier request from client terminal T. The one or more workflow scripts selected for the client request in the process of Fig. 3 are now further executed for processing the server response, in a next step 402, which may again involve activation of one or more associated function modules according to said scripts. Hence, each workflow script may include instructions both for handling the request and the subsequent response. In a last step 404, the response is finally forwarded to the server stack 202, for transfer to terminal T.

In a preferred embodiment, the operation of the proxy layer in a proxy server may be controlled by three main types of scripts: session scripts, incoming request scripts and outgoing request scripts. In the examples of script instructions given below, the client terminal is an HTTP client, although the present invention is not limited thereto. A session script specifies how the proxy layer should operate when a client terminal starts or ends a web browsing session, e.g. using HTTP or WAP. It also specifies how the proxy layer should validate that the network address of the terminal connected to the session, typically an IP address, is still allocated to the same terminal having started the session. By way of example, a session script may include the following instructions:

Instantiate some module, which we will use later. Identify the subscriber. - Generate a "Session Start" charging record.

Validate that the IP address still belongs to the same subscriber.

If different subscriber; end the session. Generate a "Session End" charging record. An incoming request script specifies how the proxy layer should operate when an incoming request is received from the client terminal directed to a web server. It also specifies how the proxy layer should operate when a response to that request from the web server is delivered to the client terminal. By way of example, an incoming request script may include the following instructions: - Send the request from the subscriber to the multipart handler,

Send the request data from the subscriber to the multipart handler,

Generate a "Request Completed" charging record, - Send the response from the multipart handler to the WAP or HTTP server stack,

Send the response data from the multipart handler to the WAP or HTTP server stack.

An outgoing request script specifies how the proxy layer should operate when an outgoing request coming from the client terminal is sent to a web server. It also specifies how the proxy layer should operate when a response to that request is received from the web server. By way of example, an outgoing request script may include the following instructions:

Add information about the subscriber to the request (as cookies or HTTP headers) .

Send the request from the multipart handler to the HTTP client. - Send the request data from the multipart handler to the HTTP client.

Store the response from the HTTP client in the cache. Send the response from the HTTP client to the multipart handler. - Store the response data from the HTTP client in the cache. Send the response data from the HTTP client to the multipart handler.

An exemplary architecture for implementing these three main types of workflow scripts and associated function modules in a script controlled proxy layer, is schematically illustrated in Fig. 5. Here, the proxy layer is again arranged between a server stack and a client stack in the same manner as shown in Fig. 2. Fig. 5 specifically illustrates the situation when a request is received from a client terminal, not shown, directed to a web server, not shown. First, the server stack 500 receives the request and forwards it to a session block 502 in the proxy layer in a step 5:1. The client request is then forwarded to a selected session script 504 in a next step 5:2. When the session script 504 is executed, one or more function modules are activated by means of instructions. The figure illustrates that an identification module 506 is activated as well as any further required function modules 508 associated with the session script 504. The incoming request 510 is then applied to a selected incoming request script 512, in a step 5:3. When the incoming request script 512 is executed, one or more function modules are activated by means of instructions. The figure illustrates that a charging module 514 is activated as well as any further required function modules 516 associated with the incoming request script 512.

In general, if a requesting client terminal supports multipart content, the proxy server can automatically fetch objects (e.g. pictures or style sheets) that are related to a root document, for delivery to the client in a single multipart response. Thus, a fetched document or the like according to an original request may refer to one or more additional embedded objects to be fetched separately from the web server.

If a response to the original request refers to such additional embedded objects, a so-called "multipart handler" in the proxy layer can be used for creating a new outgoing request for each embedded object, to be submitted to the web server. Hence, an original client request may result in one or more subsequent requests in this manner. In this example, the incoming request will in fact result in multiple outgoing requests according to the above.

Returning to Fig. 5, the request is now forwarded to a multipart handler 518 in a following step 5:4, which is configured to check the web server response and create one or more additional requests 520 depending on whether the response to the original request refers to any embedded objects. First, the original request, here denoted as outgoing request 1, is applied to a selected outgoing request script A in a step 5:5. Later, subsequent requests 520 will be applied to further outgoing request scripts 522, to be described below.

When executed, the outgoing request script A may activate one or more function modules by means of instructions. The figure illustrates that a URL filtering module 524 is activated by outgoing request script A as well as any further required function modules 526 associated with script A. After being processed by means of the outgoing request script A, the outgoing request 1 is now ready to be submitted to the target web server. Thus, request 1 is forwarded to the client stack 528, as illustrated by a step 5:6.

Upon receiving the above-handled request 1, the web server provides a response to the client stack 528, in this case referring to embedded objects that can be fetched by means of further requests. Thus, the next step 5:7 illustrates that the client stack 528 forwards the web server' s response back to the previously selected outgoing request script A for further processing which may again involve activation of associated function modules. For example, the URL filtering module 524 may again be activated in order to adapt any delivered information or visual content to requirements dictated by the client's subscription and/or prevailing policies and rules, etc.

After being processed by outgoing request script A, the response is forwarded to the multipart handler 518, as illustrated by a following step 5:8. In this example, the response refers to embedded objects resulting in another two outgoing requests 520 to be applied to another two selected outgoing request scripts 522 as follows. Thus, a subsequent second outgoing request 2 is applied to a selected outgoing request script B in a step 5:5a, and a subsequent third outgoing request 3 is applied to another selected outgoing request script C in a step 5:5b. Although not indicated in the figure, it should be understood that also scripts B and C may activate associated function modules in the same manner. Being different scripts, script B and/or script C may activate function modules different from the ones activated by script A, and so forth. Alternatively, the same outgoing request script may be selected for two or more of the requests 1, 2 and 3.

Then, requests 2 and 3 are forwarded to the client stack 528, as illustrated by further steps 5:6a and 5:6b, respectively, to be submitted to the web server. The next steps 5:7a and 5:7b illustrate that the client stack 528 forwards two incoming separate responses from the web server further to the selected outgoing request scripts B and C, respectively, for further processing which may again involve activation of associated function modules. For example, the URL filtering module 524 may again be activated in order to adapt any delivered information or visual content to requirements dictated by the client's subscription and/or prevailing policies and rules, etc.

After being processed by outgoing request scripts B and C, respectively, the two subsequent responses are forwarded to the multipart handler 518, as illustrated by following steps 5:8a and 5:8b, in order to compile them with the first response into a single combined response for delivery to the client.

The above-described steps 5:5a-5:8a and steps 5:5b~5:8b may be executed as parallel procedures for two different embedded objects found in the original response of step 5:8. It should be noted that steps 5:5a-5:8a and 5:5b- 5:8b are optional depending on whether any embedded objects are present in the response from the web server, therefore being indicated with dashed arrows in the figure. In general, any number of such embedded objects can be fetched by means of this procedure.

The multipart handler 518 compiles the individual responses of steps 5:8, 5:8a and 5:8b into a combined response which is then applied to the previously selected incoming request script 512, in a step 5:9, which when executed may activate one or more function modules in the same manner as described above.

The response is now ready for delivery to the client and is forwarded to the session block 502 in a step 5:10. The session script 504 is applied once more, in a step 5:11, in order to end the session. Finally, the response is forwarded to the server stack.500 in a step 5:12. for ... delivery to the client.

As mentioned above, the proxy layer in a proxy server may comprise plural different session, incoming and outgoing request scripts to be selected for handling each client request. The different workflow scripts may be selected according to different conditions and facts, including the type of client terminal (or user-agent) or the identity of the web server, as well as the nature of the request and/or invoked service.

An exemplary embodiment for selecting a script will now be described with reference to the flow chart illustrated in Fig. 6, to be executed in the proxy layer of a proxy server. The selected script may generally be any of the above-mentioned script types. If the architecture of Fig. 5 is used, a session script may be selected by the logic session block 502, an incoming request script may be selected by a logic block handling the incoming request 510, and outgoing request scripts may be selected by respective logic blocks handling the outgoing requests 1-3 520.

In a first step 600, a client request is received from a client terminal, directed to a specific web server. In this example, the proxy layer contains one or more "preprocessing" scripts which can be executed before executing the selected "main" script, i.e. a session script, an incoming or outgoing request script. The pre-processing scripts (not shown in Fig. 5) are designed to correct any errors or bugs that are known to generally occur in requests from specific terminal models, e.g. by adding or removing HTTP headers. Any incoming request contains information on the terminal type which is read when received by the proxy layer. Thus, in a next step 602, it is determined whether the proxy layer contains a pre-processing script that is specific for the client terminal having sent the request. If so, the terminal specific pre-processing script is selected and executed for the request in a step 604. If no such preprocessing script exists for the terminal, step 504 is naturally omitted.

Any incoming client request contains a URL pointing to a specific resource in the web server. In a next step 606, it is determined whether the proxy layer contains a main script that is specific for the URL addressed in the request. If so, the URL specific main script is selected for the request in a following step 608. By making the script selection dependent on the URL in the request, it is possible to apply an application specific behaviour in the proxy server. For example, the proxy server may operate specifically for different applications such as normal browsing, download of games or ring tones, submission/ retrieval of an MMS (Multimedia Message Service) , etc. In order to perform the determination step 606, the proxy layer may check a specific look-up table matching certain known URL's with specific scripts.

If no such URL specific script exists for the request, step 608 is naturally omitted. In that case, it is further determined in a step 610 whether the proxy layer contains a main script that is specific for the operator/ network, or "virtual gateway operator", serving the requesting client. The operator/network identity can also be read from the incoming request. If so, the operator/network specific main script is selected for the request in a following step 612. For example, the proxy server can use different subscriber identification/authentication mechanisms depending on whether it serves a GSM network or a CDMA network.

If no operator/network specific main script exists, step 612 is naturally omitted and a default main script is selected in a step 614, which is neither URL specific nor operator/network specific. In order to perform the determination step 610, the proxy layer may check a specific look-up table matching operator/network identities with specific scripts. Finally, after selecting the main script according to the above-described procedure, the selected script is executed in a last step 516. The client request is then ready to be processed by another script or unit in the proxy layer, or to be submitted to the target web server, e.g. by forwarding the request to a client stack in the proxy server.

In the example described above for Fig. 6, a specific main script may be selected depending on either the URL or the operator/network identity, after optionally applying a terminal specific pre-processing script.

Otherwise, a default script is selected. However, it should be noted that the present invention is not limited to these selection criteria, and the script selection process may be configured to select the script depending on other criteria, e.g., the type of client subscription, the identity of target web server, the time of day/week/season, the current traffic load, etc. Thus, any relevant criteria or combinations of criteria may be used for script selection, within the scope of the present invention. Moreover, different script selection procedures may be used for different operators, making the entire selection process and its criteria operator specific. Performance is crucial for successful usage of scripts in the proxy layer of a proxy server, particularly in terms of response time. Therefore, it is desirable that the proxy server does not have to load and interpret a selected script every time it is executed. When a script is to be executed, it is therefore first checked whether a binary encoded version of the script is available in an internal memory cache, according to yet another embodiment. If no binary encoded version of the script is available, or if an available binary encoded version is out-of-date and only a textual version of the valid script is available, then the textual version of the script must be loaded and translated into a binary format. If available, the valid binary version of the script can be executed immediately, which is significantly faster than the time-consuming process of loading and interpreting the textual version.

A procedure of executing a selected script with a minimum of delay will now be described with reference to a flow chart illustrated in Fig. 7. In a first step 700, a script is selected, e.g. according to the script selection procedure described for Fig. 6 above. It is then checked in a next step 702 whether a binary version of the selected script is available or not, e.g. in a local cache. If so, it is further checked in a step 704 whether the available binary version is the latest version, i.e. up-to-date.

If it is found either that no binary version of the selected script is available (in step 702), or that an available binary version is actually not the latest version, i.e. out-of-date (in step 704), a next step 706 must be performed to load a textual version and translate into an executable binary format for executed in a last step 708. On the other hand, if it is found by steps 702 and 704 that a binary version is available which is the latest version, i.e. up-to-date, that version is fetched and executed in step 708 immediately. In this way, the time-consuming process of loading and interpreting a textual version of a selected script is only performed when absolutely necessary. When implementing the present invention in a proxy server, e.g. according to one or more of the above-described embodiments, it may be much easier and less costly to modify the proxy server as compared to a conventional hard coded proxy server. For example, its functionality can easily be adapted to different services and the needs of different operators. Minor amendments and adaptations can be done directly in the workflow scripts, either by system integration personnel, or by experienced operators without requiring major efforts for changing the entire proxy layer, or even for creating a wholly new script.

Larger adaptations requiring new external interfaces can by made by implementing scriptable function modules for those interfaces. The new modules can be utilised by customer specific workflow scripts. Further, the modules may be dynamically linked to the proxy server.

While the invention has been described with reference to specific exemplary embodiments, the description is only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention. Various alternatives, modifications and equivalents may be used without departing from the concept of the invention which is not limited to any particular services, client terminals, web servers or networks. The present invention is generally defined by the appended independent claims.

Claims

1. A method of controlling a proxy server for adapting and controlling communication between a client terminal and a web server over the Internet or an

Intranet, comprising the following steps as performed in the proxy server:

- receiving a client request from the client terminal directed to the web server, - selecting a workflow script adapted to give instructions to at least one associated script- controlled function module for performing a specific function of the proxy server when handling said client request, and - executing the selected workflow script for the received client request.

2. A method according to claim 1, wherein a plurality of different workflow scripts and associated function modules are implemented in the proxy server as a proxy layer between a server stack layer facing client terminals and a client stack layer facing web servers.

3. A method according to claim 2, wherein a plurality of workflow scripts are selected for different proxy functions, including the following types of workflow scripts: a session script, an incoming request script and an outgoing request script.

4. A method according to claim 3, wherein said session script type specifies how the proxy server should operate when the client terminal starts or ends a web browsing session.

5. A method according to claim 4, wherein said session script type also specifies how the proxy server should validate that the network address of the terminal connected to the session is still allocated to the same terminal having started the session.

6. A method according to any of claims 3-5, wherein said incoming request script type specifies how the proxy server should operate when said client request is received from the client terminal, and when a response from the web server to that request is delivered to the client terminal.

7. A method according to any of claims 3-6, wherein said outgoing request script type specifies how the proxy server should operate when an outgoing request of the client terminal is sent to the web server, and when a response to that request is received from the web server.

8. A method according to any of claims 2-7, wherein said function modules perform any one of the following proxy functions: subscriber identification, access control, charging, statistics, content filtering, and format conversion.

9. A method according to claim 8, wherein at least some of the function modules are connected to external units and databases to support their functions.

10.A method according to any of claims 1-9, wherein if a response from the web server refers to one or more embedded objects and the client terminal supports multipart content, a multipart handler creates a subsequent outgoing request to the web server for each embedded object, for delivery to the client in a single multipart response.

11.A method according to claim 1, wherein said workflow script is selected based on at least one of: the type of client terminal or user-agent having sent the request, the identity of the web server, and the nature of the request and/or invoked service.

12.A method according to claim 11, wherein a preprocessing script, designed to correct any errors or bugs that are known to generally occur in requests from specific terminal models, is selected if available for the model of the requesting client terminal.

13.A method according to claim 11 or 12, wherein said workflow script is selected based on a URL given in said client request.

14.A method according to any of claims 11-13, wherein said workflow script is selected based on the identity of the operator and/or network serving the requesting client.

15.A method according to 11 or 12, wherein a default workflow script is selected if no URL-specific and/or operator/network specific workflow script is available for the client request.

16. A method according to of claims 11-15, wherein said workflow script is selected based on any of: the current type of client subscription, the current time of day/week/season, and the current traffic load.

17. A method according to of claims 1-16, wherein the selected script is executed immediately if a valid version of the script is available in binary encoded form.

18. A method according to of claims 1-17, wherein if no valid version of the selected script is available in binary encoded form and a valid version of the script is available only in textual form, the textual version of the script is loaded and translated into a binary format before being executed.

19.An arrangement in a proxy server for adapting and controlling communication between client terminals and web servers over the Internet or an Intranet, comprising:

- a plurality of workflow scripts, and

- a plurality of script-controlled function modules associated with said workflow scripts, for performing specific functions of the proxy server when handling received client requests directed to web servers, wherein each module is adapted to perform a specific function based on instructions from an associated workflow script.

20.An arrangement according to claim 19, wherein said workflow scripts and associated function modules are implemented in the proxy server as a proxy layer between a server stack layer facing client terminals and a client stack layer facing web servers.

21.An arrangement according to claim 20, wherein said workflow scripts include the following types of workflow scripts: session scripts, incoming request scripts and outgoing request scripts.

22.An arrangement according to claim 21, wherein said session script type specifies how the proxy server should operate when a client terminal starts or ends a web browsing session.

23.An arrangement according to claim 22, wherein said session script type also specifies how the proxy server should validate that the network address of the terminal connected to the session is still allocated to the same terminal having started the session.

24.An arrangement according to any of claims 21-23, wherein said incoming request script type specifies how the proxy server should operate when a client request is received from a client terminal, and when a response from a web server to that request is delivered to the client terminal.

25.An arrangement according to any of claims 21-24, wherein said outgoing request script type specifies how the proxy server should operate when an outgoing request of a client terminal is sent to a web server, and when a response to that request is received from the web server.

26.An arrangement according to any of claims 19-25, wherein said function modules are adapted to perform any one of the following proxy functions: subscriber identification, access control, charging, statistics, content filtering, and format conversion.

27.An arrangement according to claim 26, wherein at least some of the function modules are connected to external units and databases to support their functions.

28.An arrangement according to any of claims 19-27, further comprising a multipart handler adapted to, if a web server response to a client request refers to one or more embedded objects and a requesting client terminal supports multipart content, create a subsequent outgoing request ^'to the web server for each embedded object, for delivery to the client in a single multipart response.

29.An arrangement according to claim 19, further comprising means for selecting a workflow script for a particular client request directed to a web server, based on at least one of: the type of client terminal , or user-agent having sent the request, the identity of the web server, and the nature of the request and/or invoked service.

30.An arrangement according to claim 29, the script selecting means being adapted to select a preprocessing script, designed to correct any errors or bugs that are known to generally occur in requests from specific terminal models, if available for the model of the requesting client terminal.

31.An arrangement according to claim 29 or 30, the script selecting means being adapted to select said workflow script based on a URL given in said client request.

32.An arrangement according to any of claims 29-31, the script selecting means being adapted to select said workflow script based on the identity of the operator and/or network serving the requesting client.

33.An arrangement according to any of claims 29-32, the script selecting means being adapted to select a default workflow script if no URL-specific and/or operator/network specific workflow script is available for the client request.

34.An arrangement according to of claims 29-33, the script selecting means being adapted to select said workflow script based on any of: the current type of client subscription, the current time of day/week/season, and the current traffic load.

35.An arrangement according to of claims 19-34, further comprising means for executing the selected script immediately if a valid version of the script is available in binary encoded form.

36.An arrangement according to of claims 19-35, further comprising means for loading and translating an available textual version of the selected script into a binary format before being executed, if no valid version of the script is available in binary encoded form.