Java cookie Management Library and

Are you familiar with the combination of Java's cookie Management Library and j2's? Here, I would like to share with you that Internet-based client applications often play the role of small Web browsers in order to interact with websites. These sites use cookies for status management to maintain user session data.

Status Management in j2s

In the following situations, the j2e-based application requires cookie operations:

◆ Website Interaction: to interact with websites, Internet-based client applications often play the role of small web browsers. These sites use cookies for status management to maintain user session data.

◆ Network service implementation: the network service promises to make the network a friendly place for computer machines. One way to allow interaction between machines and websites is to have a network service in front of the website. Therefore, the network service displays the windows of the target website in a friendly manner on the machine. The implementation of such network services requires cookie operations to achieve real website interaction.

◆ Web browsing: for Web browsing-based Java, the cookie operation module is required to support status management.

To perform cookie operations on the client, take the following steps first:

◆ Retrieve cookies:

1. Extract cookies from the received HTTP header.

2. parse the names, values, paths, and other components of cookies respectively ).

3. Determine whether the host allows setting these cookies.

◆ Sending cookies:

1. Determine which cookies can be sent to the host.

2. determine the order of sent cookies for multiple cookies.

3. Send cookies in the same format as the outbound HTTP header.

A client-side Java application must follow all of the above steps, but using the specifications listed in RFC2965 will consume a lot of time and distract developers from the core program. As a result, developers often choose to compromise the specifications and end with the cookie operation code that is easily destroyed.

For example, suppose you want to write a Java client application that interacts with the servlet of the online store application. On the server side, when the servlet calls the request for the first time. when getsession () is a session that asks the servlet container, the container creates a new session and the server uses a session ID to retrieve the session object During Concurrent requests, the server automatically sends the session ID to the client as an HTTPcookie. In concurrent requests, the client and the request send back the same session ID together. The server uses the ID to differentiate the correct session object so that the servlet can process the request. The typical client code is as follows:

 
 

  
  
/* Get cookie. */... HttpURLConnectionhUC =
  
  
(HttpURLConnection) url. openConnection ();
  
  
 
  
  
... InputStreamis = huc. getInputStream ();
  
  
 
  
  
// Retrieve the session ID from the response. StringcookieVal =
  
  
Hc. getHeaderField ("Set-Cookie ");
  
  
 
  
  
StringsessionId; if (cookieVal! = Null) {sessionId =
  
  
CookieVal. substring (0, cookieVal. indexOf (";"));}..
  
  
 
  
  
./* Send cookie. */HttpURLConnectionhuc =
  
  
(HttpURLConnection) url. openConnection ();
  
  
 
  
  
If (sessionId! = Null) {huc. setRequestPRoperty ("Cookie", sessionId );
  
  
 
  
  
} InputStreamis = huc. getInputStream ();...
 
 

Cookie specification RFC2965 defines a new header, Set-Cookie2 for cookies version 1. If we use a new header to upgrade the server, the above Code will not be executed. The above Code cannot process multiple cookies either. In addition, the cookie value of version 1 can be a string with quotation marks. If the session cookie value is a string with quotation marks containing semicolons, this will also cause the above Code to fail. In short, the above code snippets are not isolated from the cookie version.

The above code is suitable for simple programs that only interact with a special host and path, but for a larger application, cookie management becomes more complex when multiple hosts and paths are involved. The implementation of all algorithms, security checks, and balances in cookie specifications by developers proves to be painful and futile.

Enter jCookie

To alleviate this problem, I developed a general-purpose cookie library named jCookie to implement cookie specifications. This library minimizes the additional code and effort required for client cookie operations, and enables developers to focus on core applications. Other APIs libraries, such as Apache's HTTPClient), use a structure that is removed from the built-in local java. netAPIs, so a new learning process is required. My API is a simple method to call an existing java.net object.
You can also use the developed jCookie extension, called jCookieMicro, to create an exciting customer system that can interact with network service applications on the j2's mobile device.

Now I will introduce the main behavior of jCookieAPI, starting with two main data structures:

1. Cookie class: an instance of this class indicates an independent cookie. It encapsulates all cookie attributes defined by RFC2965 and provides access to these attributes using getters and setters.

2. CookieJar class: an instance of this class is used as a container of a Cookie object set. It conforms to the set structure and provides methods to operate the cookie set.

API provides two perspectives to meet developers' requirements for cookie transparent operations and developers' requirements for advanced features. The following figure illustrates these horizons or layers.

Hierarchical view of jCookie Library