Proxy-based Hand-off of Web Sessions for User Mobility

Proxy-based Hand-off of Web Sessions for User Mobility G. Canfora°, G. Di Santo°*, G. Venturi°*, E. Zimeo°, M. V. Zito° *Department of Engineering – °RCOST, University of Sannio via Traiano, 82100 – Benevento, Italy {canfora, giuseppe.disanto, venturi, zimeo, mariavittoria.zito}@unisannio.it Abstract The proliferation of different kinds of mobile devices, ranging from personal wireless devices, such as PDAs and smart phones, to small notebooks, is enabling ubiquitous personal computing. However, even if a personal device is able to access to different kinds of information, often it does not represent the best solution to retrieve a stream of data from the Internet or to visualize it with an acceptable quality. This problem is promoting several research efforts oriented to the definition of techniques and network components able to support the migration of working sessions from a device to a more apt one. Research results related to the mobility of hosts are not sufficient to solve the problem of user mobility. The paper presents a protocol built atop HTTP for enabling session hand-off in Web applications, which, by exploiting a proxy-based architecture, is able to work without interventions on existing applications and Web infrastructure.

Keywords Web applications, computing.

session

hand-off,

mobile

1. Introduction The capability to change the host during a working session may become a very central issue in next generation networked services. In fact, while current devices have a great deal of partially overlapping capabilities (mobile phones can browse the Web, PCs can act as phones, and so on), the dream of a unique, really multipurpose, device remains very far. In real, everyday, life many people use a steeply increasing number of devices because their capabilities are very tailored to the different purposes. Moreover, communication sessions are taking an increasing time

in our life as a whole and are becoming longer taken singularly. This observation leads to two corollaries: (a) it is highly probable for a communication session to interfere with an activity requiring movement; (b) often is unforeseeable what exact kind of device we will find more suitable in the following of a session. Some examples can illustrate the intermingling of the above considerations. A driver can set a path using his car navigation system to discover later that the last part of the path is in a pedestrian zone, in which he can use the cell phone but not the car navigator; an Internet user can start navigating from the PDA and needs to start the navigation again on a PC if he discovers that a clip needs a wider screen. All these scenarios involve the capability to carry a session from a host to another. The paper investigates the capabilities of current and near future technologies to give answer to such scenarios, to assess user needs and technology limitations and to propose and experiment with possible non-invasive solutions in the context of existing applications. The technique proposed in the paper to achieve user mobility is the hand-off of Web sessions. The term “hand-off”, also known as hand-over, derives from cellular phone area. In this context, a hand-off occurs when a mobile device moves between cells: signal strength goes down and the switching to another cell is necessary to guarantee correct signal reception. In this paper, “session hand-off” (SHO) is defined as the mechanism that enables a user to change user agent during a working session with one or several hosts. The user can resume the dialog from the point left with the previous user agent, and he does not need to re-authenticate himself with the servers, to reinsert data, and to follow navigation paths again. The rest of the paper is organized as follows. Section 2 discusses two different kinds of mobility. In section 3, three different architectures for session hand-off are presented and discussed by comparing them with existing solutions for session hand-off. Section 4 describes in detail the architecture and the

protocol used to implement the session hand-off in web environment. In section 5, the execution of session hand-off is illustrated. Section 6 reports some limitations of the approach related to html. In section 7 a brief description of the proxy implementation is provided. Section 8 discusses some performance results. Finally, section 9 concludes the paper and introduces future work.

2. Background Mobile computing typically refers to two different kinds of mobility: (1) host mobility and (2) user/personal mobility. Host mobility regards the host migration from a network site to another one. The migration can involve changes of IP addresses or connection data and state. The most known approach to support host mobility from one IP subnet to another one is Mobile IP (MoIP) [1]. MoIP allows mobile computers to use Internet protocols to communicate data with network resources without changing any higher layer of the Internet protocol stack. The mobile client uses the same IP address as it moves from a place to another. So the problem of hand-off is resolved at network layer through the identification of paths to reach the mobile device and to tunnel data to deliver. However, since MoIP is intended to supply mobility support to mobile devices (i.e. the same device that moves in different networks) it does not resolve the problem of migrating a user agent between different devices. A different approach to support host mobility is to act at the transport layer of the TCP/IP protocol stack [2]. Transport Layer Seamless Handover scheme for Space Networks (TraSH-SN) [3] utilizes multi-homing to achieve a seamless hand-off, and is designed to solve some of the drawbacks of MoIP. TraSH-SN uses the Stream Control Transmission Protocol (SCTP) [4, 5] that is able to transport data maintaining the connection between client and server when an endpoint moves from an access point to another. Like the previous approach, also this one aims at keeping consistent the connection between client and server while the client device moves among different networks. User or personal mobility regards the possibility of accessing a service at anytime, anywhere, through any possible mobile/fixed device. Therefore, all the approaches that aim at supporting only host mobility could not be sufficient. Host mobility is sufficient only if the same device is adopted to access a service in different instants from different geographical points. However, in this paper we are interested also to user

access to a service from different devices. In this case, the mobility regards the user agent employed to access a service, and in particular its state. So, possible solutions to the problem can be techniques at session or application layers. Session Initiation Protocol (SIP) [6, 7] is a sessionlayer control protocol (often defined as application layer protocol due to the absence of the session layer in the TCP/IP architecture) that can establish, modify and terminate multimedia sessions or calls among one or more participants. SIP can be used with other IETF protocols to support user mobility. However, it needs many modifications on the web infrastructure and does not support the migration of information related to web sessions. Due to the current absence of an adequate protocol for supporting user mobility, some academic and industrial researchers are proposing solutions based on the introduction of a software component to collocate in the network in order to execute the desired hand-off at application layer, in the following called session hand-off.

3. Architectures for SHO Distributed applications can be seen as conceptually composed of two interacting groups of elements: a client and one or more servers. In such a context, a session can be modeled as the set of information shared by the two groups; we consider information produced by client or servers as included in the session when it may have an impact on the computation of the components of the group. In many application protocols based on a request/reply interaction scheme, such information is shared through the requests and responses exchanged. The session concept can be used also to model a different interaction, namely the interaction between the user and the client, the last one as a part of the whole distributed system. The user-client session encompasses the precise steps of interaction the user does with the client while a client-server session is land marked by requests/responses exchanges. As an example, we can consider a data collected through a web form: the client-server session evolution happens when the form is issued to the client and the data collected is sent from the client to the server. The information shared by client-server interactions does not evolve when the form is on the client, even if the user-client session undergoes to several modifications (each time the user inputs a data this becomes information shared between the user and the system).

3.2. Server-based architectural scheme In the server-based architectural scheme (Figure 2), a SHOC is put near each server.

SHOC

Application Servers

Client

3.1. Client-based architectural scheme In the client-based architectural scheme (Figure 1) the code responsible to track and store session information (the session hand-off component SHOC) is close to the client, in the same machine, possibly as a client add-on. During the normal interaction between client and servers, the SHOC simply tracks the relevant information. When a hand-off is required, such information must be transported to the SHOC component of the target client. To move the session data between SHOC, several approaches can be used, ranging from implementing a peer-to-peer scheme between SHOC components to a server that temporarily stores data.

Session Servers

Figure 2. Server-based architectural scheme. The SHOC components store information about the interaction between the clients and the server in front of which it is. After a client performs a hand-off, each SHOC is responsible to restore on the new client the proper session information. This approach has the advantage to be completely server side. Therefore, new SHOC components are managed by technically skilled people and each server administrator can decide whether implement and how to manage the session hand-off service. On the other end, a complete session hand-off service involves the recover of information shared between one client and one or more servers, so giving rise to communication and coordination among the SHOCs installed on different servers in order to properly restore the session. Moreover, since SHOC components are remote with respect to clients, they cannot have any access to information about the userclient interaction.

3.3. Proxy-based architectural scheme SHOC

SHOC

Client

over the network. On the other hand, a peer-to-peer SHOC scheme or the use of a third server can be quite complicated to be implemented. Moreover the client approach requires interventions on possibly heterogeneous clients.

SHOC

While the session between the client and the servers is fundamental for the correctness of the computation, the interaction from the user and the client is relevant for the ease of use and smoothness of the service. Therefore, in the following we extensively consider the client-servers session and cursorily take into account the user-client one. Although to achieve the session mobility many techniques can be used, the common factor of all known methodologies is the storage of session information during the interaction between the user and the application. This goal can be achieved by adopting one of three main architectural schemes, which we define as server, client and proxy based. Each one of these allows the session hand-off service to trace, freeze and successively restore a session under different assumptions and with different technical difficulties.

Application Servers

Figure 1. Client-based architectural scheme. The client-based scheme is promising since it can access all the relevant information, included those about user-client interaction that are never transmitted

The proxy-based architectural scheme (Figure 3) involves the use of an intermediate proxy, which is the SHOC, between client and servers. Differently from client-based and server-based schemes where the communication happens directly between client and server sides, in the proxy-based architectural scheme [8] communication generated by the interactions between client and servers goes through the proxy. Therefore, the proxy is able to store

all the session information even in the case in which several servers are employed for the application.

Proxy SHOC

Application Servers Client

Figure 3. Proxy-based architectural scheme. In this architecture, when a client issues a hand-off, the target client can retrieve all the information it needs from the proxy. The proxy-based technology allows for adding the service without any intervention on both client and servers. Therefore, it can be used on a large array of existing applications. Nevertheless, like a server-based scheme, a pure proxy-based approach does not allow any access to the user-client session information.

3.4. Related work and discussion Selecting an appropriate model is a matter of trade off: the server model is strong in manageability and control; the client model allows a more complete access to information to both the sessions (user-client and client-server), and the proxy model determines the lightest impact on the existing application. On the other hand server and client approaches require intervention on the infrastructure (namely the client and the servers) and involve articulated communication protocols among SHOCs to coordinate the recover of distributed session information after a hand-off. The iMASH [9] project has developed an architecture based on middleware servers capable to deal with hand-off issues in two separate layers: (1) device hand-off deals with device changes while the middleware server remains the same; (2) middleware hand-off encompasses situations in which the middleware server changes. Also a combination of the two is considered in the iMASH project. While the iMASH architecture is capable to deal with several related issues, such as client heterogeneity and content adaptation, the approach needs to individuate well-

defined save-points in the client server interaction. In legacy code this can be a problem. In the BSPM [10] project the problem is addressed with a direct intervention on the client code in which a new component is added. A server is used to pass among the new components all the session related information. When a session hand-off starts, the client owing the session puts all the data on the server where these can be retrieved by the client target of the handoff. Since we decided an engineering approach based on a minimal invasiveness on the legacy distributed application, in this paper we focus on the proxy-based approach. In the following sections, we present protocols capable to enable a session hand-off service with a proxy-based architectural approach in a well-defined context of distributed, client-server applications based on the Web.

4. Proxy-based session hand-off Although HTTP is a session-less protocol, web applications based on HTTP are expected to maintain a state for a group of interactions between client and servers. The state can be handled by the server, by the client or by both. RFC-2965 [11] has introduced the Cookie technology that directly addresses session management by storing information at client side. Other session related information can be carried out by requests and responses in authentication and user agent identification headers. In order to enable session hand-off in existing web applications, a weakly invasive architecture based on a proxy is proposed: servers see the client as a unique dummy user agent even when the client migrates from a device to another (Figure 4). To keep consistent the communication between client and server, the dummy user agent must be capable to store some data exchanged between client and server and to carry on the authentication mechanism of RFC-2617 [12] and part of the cookie management required by RFC-2965. In particular, the proxy has to implement the following activities:

User authentication: authentication of each user in order to generate a specific dummy user agent. Server authentication: whenever a server requires an authentication, the proxy has to authenticate the dummy user agent instead of the real one. Cache management: information exchanged between client and servers is to be stored notwithstanding proxy caching directives and rules.

Cookies management: the proxy has to store also cookies in order to restore them in a new user agent after a hand-off.

General header fields Upgrade: Including the protocols supported by the proxy.

Interactions before session hand-off User Web Server 1

Client 1

Proxy

Request header fields Accept: Depending on proxy current capability, possibly a subset of these in the last request.

Dummy User Agent

Client 2 (not in use)

Web Server 2

Accept-Charset: Depending on proxy current capability, possibly the same of the last request from the browser. Accept-Encoding: As above. Accept-Language: As above. Authorization: Managed by the proxy as if it was the browser (see later).

Interactions after session hand-off

Web Server 1

Client 1 (not in use)

From: The email address, if any, of the user currently authenticated on the proxy. User-Agent:

A

fake

user

agent

string.

Proxy Dummy User Agent

User

Figure 5. Dummy user agent header fields.

Client 2

Web Server 2

Figure 4. Session hand-off with a dummy user agent.

General header fields Upgrade: Modified including only the protocols supported by the proxy. Via: Modified with the proxy as request originator.

4.1. User authentication User authentication is done following the authentication rules defined in RFC-2617. After the authentication, the proxy intercepts each request and changes the header fields that can allow a server to recognize a client with a new set of headers representing the dummy user agent. So a dummy user agent can be seen as a set of data used to fill the header fields, as shown in Figure 5. Whenever the proxy receives a request from the current browser, it forwards the request after having changed header fields’ values shown in Figure 6 as illustrated in Figure 7. The server sees the request as coming from the proxy-enforced dummy user agent instead of from the original browser.

Request header fields Accept: As in the dummy user agent. Accept-Charset: As in the dummy user agent. Accept-Encoding: As in the dummy user agent. Accept-Language: As in the dummy user agent. Authorization: Replaced as described later in this document. From: As in the dummy user agent. Proxy-Authorization: The same of the original request without the current proxy authorization data. Referer: The same of the original request without proxy added information (see later). User-Agent:

As

in

the

dummy

user

agent.

Figure 6. Forwarded request header fields.

User Agent

Proxy

Dummy User Agent

Web Server

authenticates itself sends request UA Headers UA Request

forwards modified request DUA Headers Dummy UA Request

We break the authentication interactions in two halves. The proxy deals with servers following the scheme elected by them. On the other hand, the proxy deals with the user agent using the Basic scheme. This scheme is described in Figure 8 and graphically depicted in Figure 9.

User Agent

Proxy

Dummy User Agent

Web Server

Sends WWW-Authenticate Response

Figure 7. User authentication.

4.2. Server authentication

Generates Basic WWW-Authenticate Response Basic Authorization header UA Request

The proxy authentication with the servers is important to preserve the authentication after a session hand-off. If the Basic authentication scheme is used, username and password are transmitted in plain text through the proxy, hence stored by it and later reused. When the Digest authentication scheme is used, the password is not transmitted but remains on the user agent, therefore it is impossible for the proxy to store and use it after the hand-off. Step

Action

1

The proxy detects a WWW-Authenticate header in a response; it stops the response, keeps the contained data, and associates these with the authenticated user.

2

The proxy generates a Basic WWW-Authenticate fake response for the same domain from which the original response is coming and issues it to the user agent.

3

The user agent collects username and password and sends them to the proxy in an Authorization request header.

4

The proxy gets the username and password, associates these with the appropriate domain or uri list (depending on the Basic or Digest scheme), and with the authenticate user.

5

6

The proxy composes the appropriate Authorization request header for the dummy user agent, adds these in the request that originate the WWW-Authenticate response, and sends the request to the server. From now on, for each request issued by the user agent to servers in the authorization space, the proxy adds Authorization header appropriate for the dummy user agent following RFC-2617.

Figure 8. The authentication scheme.

Keeps contained data

Authenticates itself

Keeps user name and password Authorization header

Authenticates itself in place of UA

DUA Request

Figure 9. Interactions during server authentication.

4.3. Cache and cookie management HTTP/1.1 provides mechanisms to control caching in proxies. Following RFC-2616 and RFC-2965 there can be several information not stored in proxy caches but only in user agent caches. We must keep in the proxy all the information needed to restore a user agent state after a hand-off. So, our proxy must follow the principle of not discarding anything that is not surely been discarded by the client. This means to behave basically as a user agent cache instead of a proxy cache and to keep all the information that the user agent discards on exit until the user session on the proxy terminates. Moreover we need caching all the requests and responses because: (1) they contain cookies needed after a hand-off to continue a session; (2) while responses are necessary to resume a session from the last page left on the previous user agent.

5. Performing session hand-off In our model, the hand-off happens when a new user agent authenticates itself on the proxy with any currently in use account. Since authentication data is owned by the proxy, it is quite simple to re-enter authenticated sessions. However, the web session can not be completely restored since it is not aware of cookies previously exchanged by the other agent. Restoring cookies on the new client is vital for a seamless migration of the session. Moreover, a user

Step

Action

1

The proxy explores the forest and finds all the nodes containing request or response cookies;

2

Among all the cookies, possibly with the same name, only the youngest one is kept, which is the one associated with the more recent request or response;

3 4

5 6

All the nodes of the forest containing at least a cookie are arranged in a ring; For each node of the ring the proxy prepares a Redirect response carrying the nodes cookies and redirecting to the next node on the ring; The proxy issues a redirect to one of the nodes of the ring. When all the nodes in the ring have been visited all the cookies have been restored on the user agent.

Figure 10. Cookies restoring procedure. The procedure involves only the user agent and the proxy. It is worth to note that it is impossible to restore all the cookies with a single page because of the cookies acceptation rules defined in RFC-2965.

5.2. Resuming a navigation path After the cookies have been restored, the user can send a request. Some preliminary definitions help us to better explain our navigation resuming procedure (shown in Figure 11). Basing on the requested URI, an area is determined as follows: If the URI contains only a domain name, the area encompasses all the resources on all the hosts of this domain; If the URI contains a fully specified hostname, the area encompasses all the resources on this host;

Normal Operations

Dummy User Agent

Target User Agent Authentication

In our approach, after the session hand-off, the cookies are restored in a unique batch (see Figure 11). This can slow down resuming a session but it allows to quickly resume normal operation mode. In particular, since the previously visited resources can easily be seen as a forest in the proxy cache, resuming a session involves the operations of Figure 10:

User Agent

Web Server

Proxy

Target User Agent Generic Request Proxy-Authenticate Response Proxy-Authorization Request Hand-off

Cookie Restoring

5.1. Restoring cookies

If the URI contains a path, the area encompasses all the resources having the URI as a prefix. With referring to an area the Last Previously Visited Page (LPVP) is the page in that area that received the last visit before the hand-off. With previously visited we will refer to areas or resources visited before the hand-off.

Last Page restoring

can interact with more than one server and can visit a page quite deep in the web structure of a server.

Cookie Management Response Request Cookies Restoring Response Request

LPVP

LPVP Individuation

Request Request Response

Response

Figure 11. Whole hand-off procedure. We can have three different kinds of first request after a hand-off: the Request URI specifies a resource not previously visited: the proxy can send the request to a server after inserting the dummy user agent; the Request URI specifies a previously visited resource: the proxy must send the client the cached response; the Request URI specifies a previously visited area: the proxy individuates the LPVP and redirects the user agent to it. Then it sends the cached response.

6. Sessions and html When HTTP is used to present HTML pages some other considerations have to be made in order to properly restore the LPVP on the user agent. If some page contains frames or layers, it can often happens that the LPVP only encompasses a part of what the

user expects to see after the session resumption. This is because navigating with frames and layers entails to include the result of a request in a page showing results of earlier interactions as well. To restore a coherent page on the browser we need to address two related issues: We need to not resend the LPVP as previously defined but the page which defines the structure, frames or layer, containing the LPVP (we will call this page the LPVPRoot in the following) and the other included pages as well; We must modify the LPVPRoot since the cached original one can contain no links to the LPVP; the LPVP can be not directly called by the LPVPRoot but trough other pages. Note that LPVPRoot can have its including page as well. We recur to a URL rewriting approach allowing us to trace inclusion relations. Step

During navigation

1

When the proxy detects a page containing the Frame or Layer HTML tag, it annotates the URL in anchors (having a destination on the same page) with an automatically generated identifier.

2

When the proxy detects an annotated URL in a request it removes the annotation; then it sends the request to the server.

3

When a response is received, the proxy stores the information that this response has been sent as a result of the annotated anchor. Than, the proxy annotates all the anchors in the page having itself as destination.

rebuild a consistent LPVPRoot after a hand-off are respectively shown.

7. Implementation details The proxy presented in this paper, called MuffinSH, was implemented by using Java. It was built by extending a filtering system, Muffin [13] freely available under GNU General Public License, and supports HTTP/0.9, HTTP/1.0, HTTP/1.1 and SSL. The first release is available at http://www.rcost.unisannio.it/sessionHandoff. MuffinSH uses the filters (see Figure 14) inherited from the Muffin interfaces to implement the session hand-off. The main interfaces implemented by MuffinSH are: RequestFilter, ReplyFilter, ContentFilter, HttpFilter, and RedirectFilter. The RequestFilter interface is implemented by the filters that handle request headers; ReplyFilter is used for response headers; ContentFilter processes the content of responses; HttpFilter is used to generate replies to requests that do not need of being sent to the server; RedirectFilter redirects an URL to another. By using the filters, the proxy is able to store, for each user and each domain, web content replied by a server to a client before the user hands-off the session.

.....

user 1

.....

user i

Request

user n

Filtered response

ProxyAuthFilter Proxy

Figure 12. Tracing inclusion relations among pages

CachedReplyFilter

during navigation. user 1

user i+1

After a hand-off

1

If proxy detects that a LPVP is included in some other page, it traces the inclusion relations and, each time it finds a page with Layers or Frames, it substitutes the addresses called in original content anchors in the page with the more recent ones resulting from inclusion relations with the appropriate destination.

2

The procedure stops when the proxy reaches a LPVPRoot included in no pages. Then the proxy redirects the user agent to this page.

Figure 13. Rebuilding a consistent LPVPRoot after

HeaderChangeFilter

.....

Step

.....

ServerAuthFilter

CacheFilter user i

UrlRedirectFilter

user n

RedFilter

Response

Filtered request

Internet Web Server

hand-off.

In Figure 12 and Figure 13, the procedure to trace inclusion relations during navigation and how to

Figure 14. Filter-based architecture of MuffinSH.

proxy

100

user

80

automatic

60 40 20

This section shows some performance figures obtained with a dedicated testbed composed of three computers connected through a Fast Ethernet local network. The same configuration of PCs is being adopted to test the proxy in a non-dedicated environment through a network emulator and a traffic generator. However, a non-dedicated testbed will emphasize the difference of performance between

16

14

12

10

8

6

4

0

2

Restoring time (s)

Session restoring tim es w ith different # of cookies

Htm l pages containing cookies

Figure 15. Restoring times. As the figure shows, user and automatic browsing time grows linearly with the number of pages containing cookies, whereas the proxy is able to restore the whole session after a hand-off in a time that is independently of the deep of the navigation path. Embedded objects 800

proxy user

600

automatic

400 200

16

14

12

10

8

6

4

0 2

8. Performance analysis

manual navigation and the automatic proxy-mediated one, since the Proxy acts also as a Web cache. Figure 15 reports the time needed to restore a session characterized by a varying number of pages containing cookies encountered during the navigation. In particular, several measurements were performed in three different ways: (1) by using the proxy; (2) by navigating manually to restore a session; (3) by repeating a navigation path through the use of a tool able to register user actions performed on the browser.

Requested embedded objects

The above interfaces were implemented by the following filters: ProxyAuthFilter: implements HttpFilter; the filter verifies whether all attained requests contain the “Proxy-Authorization” header. If it is not present or username and password are not correct, the filter requires a Proxy-Authorization with the basic authentication scheme and does not forward the request to the server. If user credentials are correct, the filter only verifies whether the authentication is issued before or after a hand-off. CachedReplyFilter: implements HttpFilter; when a user issues a request after a hand-off, the filter verifies whether the domain of the requested resource exists in the proxy cache and, in positive case, it creates a response to send the client the resource stored in cache. ServerAuthFilter: implements RequestFilter and ReplyFilter; it acts when a server asks the user for the authentication. HeaderChangeFilter: implements RequestFilter; it changes the request headers to allow the server to recognize the client with a new set of headers representing a dummy user agent. CacheFilter: implements ContentFilter; before a hand-off occurs, this filter acts on the content of responses characterized by a text/html content-type; it analyzes the received html tags and basing on this analysis manages the pages containing frames, the pages implementing the contained frames and the pages referred inside the frames. UrlRedirectFilter: implements RedirectFilter; when this filter intercepts in the request URL some identifiers previously inserted by CacheFilter, it eliminates the identifiers, stores the related information and forwards the request to the server. RedFilter: implements RedirectFilter; it works after the occurrence of a hand-off and; the filter makes a redirection to the URL requested from the client before the hand-off in order to re-collect all the cookies previously received by the client in response to that request.

Html pages containing cookies

Figure 16. Number of objects per session. This behavior is motivated by the proxy ability of restoring the session by sending only cookies to the browser, whereas user and automatic session restoring need to download all the pages containing cookies already downloaded before the hand-off on the

previous device. Figure 16 highlights the rationale underlying the interesting behavior shown in Figure 15 by indicating the number of embedded objects to download with user and automatic session restoring.

9. Conclusion and future work In this paper we addressed the problem of session hand-off in Web application through a weakly invasive, proxy based architectural approach. The approach does not require modifications to Web applications and makes it possible a great deal of control on the session. At the current stage the principal limitation of the proxy approach is the incapability to deal with embedded code in HTML pages. However, since there are several business applications strictly respecting these limitations, namely using only HTML, the current implementation can be widely used. Nevertheless, to improve our approach usability in real world situations, we need to deal with some more issues that correspond to our future research directions. To make the proxy able to manage the authentication on behalf of the client, we break the HTTP 1.1 security. This imposes some confidentiality issues that have to be addressed: the user must be aware that his credentials are transmitted to the proxy and stored by it and the communication between the client and the proxy must be secured by means of other approaches. By adopting a pure proxy based approach we lose visibility on the user-client session evolution also in a pure HTTP-HTML session. We need to evaluate the measure in which is important for the user to handle such information and possibly to devise mechanisms to supply the service. Often web pages contain embedded script code, primarily ECMA code (a.k.a. JScript) but possibly VBScript and other as well. With such a code a pure proxy based approach loses the control on the userclient session in a more dramatic way. Not only the proxy is unable to restore part of the content of the page but it can become unable to restore a page consistent with the user expectance as well. This because script code can change the appearance of the page while on the client. The problem can be resolved by means of a mixed approach involving a partial client modification.

10. References [1] C. Perkins, “IP Mobility Support for IPv4”, RFC 3220, Internet Engineering Task Force, January 2002. http://www.rfc-editor.org/rfc/rfc3220.txt. [2] A. C. Snoeren, and H. Balakrishnan, “An End-to-End Approach to Host Mobility”, In Procs. of ACM MOBICOM 2000, Boston, USA, August 2000, pp. 155-166. [3] M. Atiquzzaman, S. Fu, and W. Ivancic, “TraSH-SN: A Transport Layer Seamless Handoff Scheme for Space Networks”, in Procs of fourth Earth Science Technology Conference (ESTC), Crowne Plaza Cabaña, Palo Alto CA, June 2004. [4] R. Stewart, and C. Metz, “SCTP: New transport protocol for TCP/IP”, IEEE Internet Computing, vol. 5, n. 6, November/December 2001, pp. 64-69. [5] S. Fu, and M. Atiquzzaman, “SCTP: State of the art in Research, Products, and Technical Challenges”, IEEE Communications Magazine, vol. 42, n. 4, April 2004, pp. 6476. [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: Session Initiation Protocol”, RFC 2543, Internet Engineering Task Force, March 1999. http://www.rfc-editor.org/rfc/rfc2543.txt. [7] H. Schulzrinne, and E. Wedlund, “Application-Layer Mobility using SIP”, in Mobile Computing and Communications Review, vol. 4, n. 3, July 2000, pp. 47-57. [8] G. Canfora, G. Di Santo, G. Venturi, E. Zimeo, and M. V. Zito, “Migrating Web Application Sessions in Mobile Computing”, in Procs. of WWW2005, Chiba, Japan, 10-14 May 2005, pp. 2. [9] R. Bagrodia, S. Bhattacharyya, F. Cheng, S.Gerding, G. Glazer, R. Guy, Z. Ji, J. Lin, T.Phan, E. Skow, M. Varshney, and G. Zorpas, “iMASH: Interactive Mobile Application Session Handoff”, in Procs of the ACM International Conference on Mobile Systems, Applications, and Services, San Francisco, May 2003. [10] H. Song, H. Chu, and S. Kurakake, “Browser Session Preservation and Migration”, in Procs. of WWW2002, Hawaii, USA, 7-11 May 2002, pp. 2. [11] D. Kristol, and L. Montulli, “HTTP State Management Mechanism”, RFC 2965, Internet Engineering Task Force, Octber 2000. http://www.rfc-editor.org/rfc/rfc2965.txt. [12] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication”, RFC 2617, Internet Engineering Task Force, June 1999. http://www.rfceditor.org/rfc/rfc2617.txt.

[13] Muffin: World http://muffin.doit.org/.

Wide

Web

Filtering

System.