• User Sessions and the Session Service

• Sessions, Session Tokens, and Cookies

• Policy Agents

• Basic User Session

• Single Sign-On Session

• Cross-Domain Single Sign-On Session

• Session Termination

User Sessions and the Session Service

The Session Service in Sun Java System Access Manager tracks a user’s interaction with web applications. For example, the Session Service maintains information about how long a user has been logged in to Access Manager, and enforces time-out limits when necessary. Additionally, the Session Service performs the following actions:

• Generates session identifiers.

• Maintains a master copy of session state information.

• Implements time-dependent behavior of sessions.

• Implements session life cycle events such as logout and session destruction.

• Generates session life cycle event notifications.

• Generates session property change notifications.

• Implements session quota constraints.

• Implements session failover.

• Enables single sign-on (SSO) and cross-domain single sign-on (CDSSO) among applications external to Access Manager.

A user session is the interval between the moment a user logs in to Access Manager, and the moment the user logs out of Access Manager. In a typical user session, an employee attempts to access the corporate benefits administration application. The application is protected by Access Manager, and Access Manager prompts the user for a username and password. First, Access Manager authenticates, or verifies that the user is who he says he is. Following user authentication, Access Manager allows the user access to the application (providing the user has the appropriate permissions). For a more detailed explanation, see Basic User Session.

Oftentimes, in the same user session (without logging out of the corporate benefits application), the same employee attempts to access the corporate expense reporting application. Because the expense reporting application is also protected by Access Manager, the Session Service provides continued proof of the user’s authentication, and the employee is automatically allowed to access the expense reporting application. The employee has accessed more than one application in a single user session without having to re-authenticate. This functionality is called Single Sign-On (SSO). When SSO occurs among applications in more than one DNS domain, the functionality is called Cross-Domain Single Sign-On (CDSSO). For more detailed explanations, see Single Sign-On Session and Cross-Domain Single Sign-On Session, respectively.

Sessions, Session Tokens, and Cookies

The Access Manager Session Service creates a session data structure to store information about a user session and uses cookies to store a token that identifies the session data structure. When a user logs in and is successfully authenticated, the user is assigned a session, a session data structure that, minimally, stores the following information about a user session:

Maximum Idle Time

Maximum number of minutes without activity before the session will expire and the user must reauthenticate.

Maximum Session Time

Maximum number of minutes (activity or no activity) before the session expires and the user must reauthenticate.

Maximum Caching Time

Maximum number of minutes before the client contacts Access Manager to refresh cached session information.

Internally, these session attributes are used to enforce Access Manager timeout limits. But a session can also contain additional attributes and properties which can be used by other applications. For example, a session data structure can store information about a user’s identity, or about a user’s browser preferences. You can configure Access Manager to include the following types of information in a session:

• Fixed session attributes

• Protected properties

• Custom properties

For a detailed summary of information that can be included in a session, see Configuring Access Manager Sessions in the Sun Java System Access Manager 7.1 Postinstallation Guide.

The Session Service also generates a session token for the new session data structure. The session token, also known as a sessionID, is an encrypted, unique string that identifies the specific session instance. If the session token is known to a protected resource such as an application, the application can access the session and all user information contained in it. In Access Manager, a session token is carried in a cookie. A cookie is an information packet generated by a web server and passed to a web browser. The fact that a web server generates a cookie for a user does not guarantee that the user is allowed access to protected resources. The cookie simply points to user information in a data store from which an access decision can be derived.

Cookies are domain-specific. For example, a cookie generated by a web server within Domain A cannot be used by a web server in Domain B. Cookies can be passed only between servers in the same domain in which the cookie was set. Similarly, servers can set cookies only on servers within in their own domain.

Policy Agents

Policy agents are an integral part of SSO and CDSSO sessions. They are programs that police the web server or application server that hosts protected resources. When a user requests access to a protected resource such as a server or an application, the policy agent intercepts the request and redirects it to the Access Manager Authentication Service for authentication. Following this, the policy agent will also enforce the authenticated user’s assigned policies. (A policy defines the rules that specify a user's access privileges to a protected resource.) Access Manager supports two types of policy agents:

• The web agent enforces URL-based policy for C applications.

• The J2EE/Java agent enforces URL-based policy and J2EE-based policy for Java applications on J2EE containers.

Both types of agents are available for you to install as programs separate from Access Manager. For an overview of the available policy agents and links to specific information on installation, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.

When Access Manager policy agents are implemented, all HTTP requests are implicitly denied unless explicitly allowed by the presence of two things:

1. A valid session

2. A policy allowing access

You can modify this default configuration so that Access Manger implicitly allows access unless explicitly denied.

Basic User Session

The following sections describe the process behind a basic user session by tracing what happens when a user logs in to a resource protected by Access Manager. In these examples, the server which hosts an application is protected by an Access Manager policy agent. The Basic User Session includes the following phases:

• Initial HTTP Request

• User Authentication

• Session Validation

• Policy Evaluation and Enforcement

• Logging Results

Initial HTTP Request

When a user initiates a user session by using a browser to log in to a web-based application, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–1 Initial HTTP Request

1. The user’s browser sends an HTTP request to the protected resource.

2. The policy agent inspects the user’s request and finds no session token.

3. The policy agent contacts the configured authentication URL.

   In this example, the authentication URL it is set to the URL of the Distributed Authentication User Interface Service.

4. The browser sends a GET request to the Distributed Authentication User Interface.

5. The Session Service creates a new session (session data structure) and generates a session token. The session token is a randomly-generated string that represents the user.

6. The Authentication Service sets the session token in a cookie.

The next part of the user session is User Authentication.

User Authentication

When the browser sends a GET request to the Distributed Authentication User Interface, the events in the following illustration occur. The accompanying text describes the process.

1. Using the parameters in the GET request, the Distributed Authentication User Interface contacts the Authentication Service installed on the Access Manager server.

2. The Authentication Service determines the appropriate authentication module to use based upon Access Manager configuration and the request parameters passed by the Distributed Authentication User Interface using the Authentication client APIs.

   For example, if Access Manager is configured to use the LDAP Authentication type of module, the Authentication Service determines that the LDAP Authentication login page will be used.

3. The Authentication Service determines which presentation callbacks should be presented, and sends to the Distributed Authentication User Interface all necessary credentials, requirements, and callbacks for use by the presentation framework layer.

4. The Client Detection Service determines which protocol, such as HTML or WML, to use to display the login page.

5. The Distributed Authentication User Interface returns to the Web browser a dynamic presentation extraction page along with the session cookie.

   The presentation extraction page contains the appropriate credentials request and callbacks info obtained from the Access Manager server.

6. The user’s browser displays the login page.

   The user enters information in the Username and Password fields of the login page.

7. The browser replies to the Distributed Authentication User Interface with a POST that contains the required credentials.

8. The Distributed Authentication User Interface uses the Authentication client APIs to pass credentials to the Access Manager server.

9. The Authentication Service uses the appropriate authentication module type to validate the user’s credentials.

   For example, if the LDAP authentication module type is used, the Authentication Service verifies that the username and password provided exist in the LDAP directory. Other authentication module types have different requirements.

10. Assuming authentication is successful, the Authentication Service activates the session by calling the appropriate methods in the Session Service.

    The Authentication Service stores information such as Login time, Authentication Scheme, and Authentication Level in the session data structure.

11. Once the session is activated, the Session Service changes the state of the session token to valid.

12. The Distributed Authentication User Interface replies to the protected resource with an SSOToken in a set-cookie header.

13. Now, the browser makes another request to the original resource protected by a policy agent.

    This time, the request includes a valid session token, created during the authentication process.

The next part of the user session is Session Validation.

Session Validation

After authentication, when the user’s browser redirects the initial HTTP request to the server for a second time, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–2 Session Validation

1. The policy agent intercepts the second access request.

   The request now contains a session token in the same DNS domain as Access Manager.

2. The policy agent determines the validity of the session token.

   1. The policy agent contacts the Naming Service to learn where the session token originated.

      The Naming Service allows clients to find the service URL for the internal services used by Access Manager. This information can then be used for communication regarding a session.

   2. The Naming Service decrypts the session token and returns the corresponding URLs . The URLs will be used by other services to obtain information about the user session.

3. The policy agent, using the information provided by the Naming Service, makes a POST request to the Session Service to validate the included session token.

4. The Session Service receives the request and determines whether the session token is valid based on the following criteria:

   1. Has the user been authenticated?

   2. Does a session data structure associated with the session token exist?

5. If all criteria are met, the Session Service responds that the session token is valid.

   This assertion is coupled with supporting information about the user session itself.

6. The policy agent creates a Session Listener and registers the Session Listener with the Session Service. This enables notification to the policy agent when a change in the session token state or validity occurs.

The next part of the user session is Policy Evaluation.

Policy Evaluation and Enforcement

After a session token has been validated, the policy agent determines if the user can be granted access to the server by evaluating it's defined policies. The following illustration and accompanying text describes the process.

Figure 2–3 Policy Evaluation

1. The policy agent sends a request to the Policy Service.

   The request asks for decisions regarding resources in the policy agent’s portion of the HTTP namespace. The request also includes additional environmental information. For example, IP address or DNS name could be included in the request because they might impact conditions set on a configuration policy.

2. The Policy Service checks for policies that apply to the request.

   Policies are cached in Access Manager. If the policies have not been cached already, then the policies are loaded from the Access Manager information tree in the Identity Repository.

3. If policies that apply to the request are found, the Policy Service checks if the user identified by the session token is a member of any of the Policy Subjects.

   1. If no policies that match the resource are found, the user is denied access. Skip to step 5.

   2. If policies are found that match the resource, and the user is a valid subject, the Policy Service evaluates the conditions of each policy. For example, Is it the right time of day? or Are requests coming from the correct network?

      • If the conditions are met, the policy applies.

      • If the conditions are not met, the policy is skipped.

4. The Policy Service aggregates all policies that apply, encodes a final decision to grant or deny access, and responds to the policy agent with the appropriate decision.

The next part of the user session is logging the policy evaluation results.

Logging Results

When the policy agent receives an allow decision from the Policy Service, the events in the following illustration occur. The accompanying text describes the process.

Figure 2–4 Logging the Policy Evaluation Results

1. The allow decision is cached in the policy agent, along with the session token, so that subsequent requests can be checked using the cache.

   It is no longer necessary for the policy agent to contact Access Manager. The cache will expire after an interval has passed or upon an explicit notification of change in policy or session status. The interval is configurable.

2. The policy agent issues a logging request to the Logging Service.

3. The Logging Service logs the policy evaluation results to a flat file (which can be signed) or to a JDBC store, depending upon the log configuration.

4. The Logging Service notifies the policy agent of the new log.

5. The policy agent allows or denies the user access to the application.

   1. If the user is denied access, the policy agent displays an “access denied” page.

   2. If the user is granted access, the resource displays its access page.

   Assuming the browser displays the application interface, this basic user session is valid until it is terminated. See Session Termination.

While the user is still logged in, if he attempts to log into another protected resource, the Single Sign-On session begins.

Single Sign-On Session

SSO is always preceded by a basic user session in which a session is created, its session token is validated, the user is authenticated, and access is allowed. SSO begins when the authenticated user requests a protected resource on a second server in the same DNS domain. The following example describes an SSO session by tracing what happens when an authenticated user accesses a second application in the same DNS domain as the first application. Because the Session Service maintains user session information with input from all applications participating in an SSO session, in this example, it maintains information from the application the user was granted access to in Basic User Session. We will assume the application previously accessed was a corporate benefits administration application. For this SSO session, the user is attempting access to an expense reporting application.

Figure 2–5 Single Sign-On Session

1. The user attempts to access an expense reporting application.

   Both the expense reporting application and the corporate benefits administration application are hosted on servers in the same domain.

2. The user’s browser sends an HTTP request to the expense reporting application. The request includes the user’s session token.

3. The policy agent intercepts and inspects the request to determine whether a session token exists.

   A session token indicates the user is already authenticated. Since the user was authenticated when the user logged in to the corporate benefits administration application, the Authentication Service is not required at this time. The SSO APIs retrieve the session data structure using the session token imbedded in the cookie. The session data structure is referred to as the SSOToken by the SSO APIs. The session token is referred to as the SSOTokenID.

4. The policy agent determines the validity of the session.

   For detailed steps, see Session Validation.

5. The Session Service sends a reply to the policy agent indicating whether the SSOToken is valid.

   • If the SSOToken is not valid, the user is redirected to the Authentication page.

   • If the SSOToken is valid, the Session Service creates a Session Listener.

     A Session Listener allows notification to the policy agent when a change in the SSOToken state or validity occurs.

6. The policy agent sends a request to the Policy Service.

   The request asks for a decision regarding resources in the policy agent’s portion of the HTTP namespace.

7. The Policy Service checks for policies that apply to the request.

   • If Policy Service does not find policy allowing access to the protected resource, the user is denied access and the following events occur:

     1. The Logging Service logs a denial of access.

     2. The policy agent issues a Forbidden message to the user.

        The user can then be redirected to an administrator-specified page indicating the user was denied access.

   • If the Policy Service finds policy allowing access to the protected resource, the user is granted access to the protected resource and the SSO session is valid until it is terminated. See Session Termination.

While still logged in, if the user decides to attempt to log in to another protected resource located in a different DNS domain, Cross-Domain Single Sign-On takes place.

Cross-Domain Single Sign-On Session

CDSSO occurs when an authenticated user requests a protected resource on a different server in a different DNS domain. The user in the previous sections, Basic User Session and Single Sign-On Session, for example, accessed applications in his company’s DNS domain. In the following example, the same user will log in to a travel administration application supplied to his company by an external company. The travel administration application is hosted on the external company’s DNS domain. In this scenario, the CDSSO Controller Service within Access Manager transfers the user’s session information from the initial domain, making the it available to applications in this second domain.

When the user logs in to the travel administration application in the external DNS domain, the events in the following illustration occur. The process is described in the accompanying text.

1. The user’s browser sends an HTTP request to the travel administration application.

2. The policy agent intercepts the request and inspects it to determine if a session token exists for the domain in which the travel administration application exists. One of the following occurs:

   • If a session token is present, the policy agent validates the session.

   • If no session token is present, the policy agent (which is configured for CDSSO) redirects the HTTP request to the CDSSO Controller Service.

     ---

     Note –

     The CDSSO Controller Service uses Liberty Alliance Project protocols to transfer sessions so the relevant parameters are included in the redirect.

     ---

   In this example, no session token for the second domain is found.

3. The policy agent redirects the HTTP request to the CDSSO Controller Service.

4. The user’s browser allows the redirect to the CDSSO Controller Service.

   Recall that earlier in the user session the session token was set in a cookie in the initial domain which is now part of the redirect.

5. The CDSSO Controller Service's CDC Servlet receives the session token from the initial domain, extracts the user's session information, and formulates a Liberty POST profile response containing the information. The response is returned to the browser.

6. The user’s browser automatically submits the form containing the Liberty document to the policy agent.

   The form is based upon the Action and the Javascript included in the Body tags onLoad.

7. The policy agent receives the document, extracts the session information, validates the session, and sets a session token in the cookie for the new DNS domain.

   For detailed information, see Session Validation.

8. The process continues with policy evaluation and results logging.

   See the following sections for detailed information.

   • Policy Evaluation and Enforcement

   • Logging Results

9. The policy agent allows or denies the user access to the application.

   1. If the user is denied access, the policy agent displays an “access denied” page.

   2. If the user is granted access, the resource displays its access page.

Assuming proper authorization, the policy agent responds to the user by presenting the travel administration application screen. This new cookie can now be used by all agents in the new domain, and the session is valid until it is terminated. (See Session Termination.)

Session Termination

A user session can be terminated in any of following ways:

• User Ends Session

• Administrator Ends Session

• Access Manager Enforces Timeout Rules

• Session Quota Constraints

User Ends Session

When a user explicitly logs out of Access Manager by clicking on a link to the Logout Service the following events occur:

1. The Logout Service receives the Logout request, and performs the following steps:

   1. Marks user’s session as destroyed.

   2. Destroys session.

   3. Returns a successful logout page to the user.

2. The Session Service notifies applications which are configured to interact with the session.

   In this case, each of the policy agents was configured for Session Notification, and each is sent a document instructing the agent that the session is now invalid.

3. The policy agents flush the session from cache and the user session ends.

Administrator Ends Session

Access Manager administrators with appropriate permissions can terminate a user session at any time. When an administrator uses the Sessions tab in the Access Manager console to end a user’s session, the following events occur:

1. The Logout Service receives the Logout request, and performs the following steps:

   1. Marks user’s session as destroyed.

   2. Destroys session.

2. The Session Service notifies applications which are configured to interact with the session.

   In this case, each of the policy agents was configured for Session Notification, and each is sent a document instructing the agent that the session is now invalid.

3. The policy agents flush the session from cache and the user session ends.

Access Manager Enforces Timeout Rules

When a session timeout limit is reached, the Session Service completes the following steps:

1. Changes session status to invalid.

2. Displays time-out message to user.

3. Starts timer for purge operation delay (default is 60 minutes).

4. When purge operation delay time is reached, purges or destroys the session.

5. If a session validation request comes in after the purge delay time is reached, displays login page to user.

Session Quota Constraints

Access Manager allows administrators to constrain the amount of sessions one user can have. If the user has more sessions than the administrator will allow, one (or more) of the existing sessions can be destroyed.

有些字符在HTML里有特别的含义，比如小于号<就表示HTML Tag的开始，这个小于号是不显示在我们最终看到的网页里的。那如果我们希望在网页中显示一个小于号，该怎么办呢？

这就要说到HTML字符实体(HTML Character Entities)了。

一个字符实体(Character Entity)分成三部分：第一部分是一个&符号，英文叫ampersand；第二部分是实体(Entity)名字或者是#加上实体(Entity)编号；第三部分是一个分号。

比如，要显示小于号，就可以写&lt;或者<。

用实体(Entity)名字的好处是比较好理解，一看lt，大概就猜出是less than的意思，但是其劣势在于并不是所有的浏览器都支持最新的Entity名字。而实体(Entity)编号，各种浏览器都能处理。

注意：Entity是区分大小写的。

如何显示空格

通常情况下，HTML会自动截去多余的空格。不管你加多少空格，都被看做一个空格。比如你在两个字之间加了10个空格，HTML会截去9个空格，只保留一个。为了在网页中增加空格，你可以使用&nbsp;表示空格。

最常用的字符实体(Character Entities)

其他常用的字符实体(Character Entities)

更多字符实体(Character Entities)

更多字符实体(Character Entities)请参见 ISO Latin-1字符集。

ISO Latin-1字符集

　　一、继承

　　CSS的一个主要特征就是继承，它是依赖于祖先-后代的关系的。继承是一种机制，它允许样式不仅可以应用于某个特定的元素，还可以应用于它的后代。例如一个BODY定义了的颜色值也会应用到段落的文本中。下面举例说明：

　　样式定义：body{color:red;}

　　应用举例代码：

CSS的层叠和继承深入探讨

　　应用举例效果：

　　这段代码的应用结果是：“CSS的层叠和继承深入探讨”这段话是红颜色的，“层叠和继承”由于应用了strong元素，所以是粗体。这很符合制作者的意图，也是为什么继承是CSS的一部分的原因。

二、CSS继承的局限性

　　在CSS中，继承是一种非常自然的行为，我们甚至不需要考虑是否能够这样去做，但是继承也有其局限性。

　　首先，有些属性是不能继承的。这没有任何原因，只是因为它就是这么设置的。举个例子来说：border属性，大家都知道，border属性是用 来设置元素的边框的，它就没有继承性。如下图所示，如果继承了边框属性，那么文档看起来就会很奇怪，除非采取另外的措施关掉边框的继承属性。

　　如上图所示，多数边框类属性，比如象Padding（补白），Margin（边界），背景和边框的属性都是不能继承的。

三、继承中容易引起的错误

　　有时候继承也会带来些错误，比如说下面这条CSS定义：

　　Body{color:blue}

　　在有些浏览器中这句定义会使除表格之外的文本变成蓝色。从技术上来说，这是不正确的，但是它确实存在。所以我们经常需要借助于某些技巧，比如将CSS定义成这样：

　　Body,table,th,td{color:blue}

　　这样表格内的文字也会变成蓝色。

　　四、多种样式混合应用

　　既然有了继承性，那么在样式表中的应用上可能会有些读者搞不清，多个样式表同时应用到一个对象上会发生什么情形呢？先举个简单的例子：

　　样式定义：.apple{color:red;}　　H1{color:yellow;}

　　应用举例代码：<H1 CLASS=”apple”>这儿的苹果好红啊</H1>

　　应用举例效果：因为选择符H1和.apple都匹配上面的H1元素，那么到底浏览器会应用哪一个呢？通过在浏览器中观察，我们发现这段文字应用了.apple这个样式，所以它显示的是红色。这是因为两条规则的特殊性不一样，CSS规则必须这样进行处理。

　　样式表中的特殊性描述了不同规则的相对权重，它的基本规则是：

　　统计选择符中的ID属性个数。
统计选择符中的CLASS属性个数。
统计选择符中的HTML标记名格式。

　　最后，按正确的顺序写出三个数字，不要加空格或逗号，得到一个三位数。( 注意，你需要将数字转换成一个以三个数字结尾的更大的数)。相应于选择符的最终数字列表可以很容易确定较高数字特性凌驾于较低数字的。

　　以下是一个按特性分类的选择符的列表：

　　H1 {color:blue;}                        特性值为：1
P EM {color:purple;}                    特性值为：2
.apple {red;}                           特性值为：10 
P.bright {color:yellow;}                  特性值为：11
P.bright EM.dark {color:brown;}           特性值为：22
#id316 {color:yellow}                   特性值为：100

　　从上表我们可以看出#id316具有更高的特殊性，因而它有更高的权重。当有多个规则都能应用于同一个元素时，权重越高的样式将被优先采用。

作者:jaddy0302 日期:2006-12-21

字体大小: 小 中 大

一般的情况下我们都是使用IE或者Navigator浏览器来访问一个WEB服务器，用来浏览页面查看信息或者提交 一些数据等等。所访问的这些页面有的仅仅是一些普通的页面，有的需要用户登录后方可使用，或者需要认证以及是一些通过加密方式传输，例如HTTPS。目前 我们使用的浏览器处理这些情况都不会构成问题。不过你可能在某些时候需要通过程序来访问这样的一些页面，比如从别人的网页中“偷”一些数据；利用某些站点 提供的页面来完成某种功能，例如说我们想知道某个手机号码的归属地而我们自己又没有这样的数据，因此只好借助其他公司已有的网站来完成这个功能，这个时候 我们需要向网页提交手机号码并从返回的页面中解析出我们想要的数据来。如果对方仅仅是一个很简单的页面，那我们的程序会很简单，本文也就没有必要大张旗鼓 的在这里浪费口舌。但是考虑到一些服务授权的问题，很多公司提供的页面往往并不是可以通过一个简单的URL就可以访问的，而必须经过注册然后登录后方可使 用提供服务的页面，这个时候就涉及到COOKIE问题的处理。我们知道目前流行的***页技术例如ASP、JSP无不是通过COOKIE来处理会话信息 的。为了使我们的程序能使用别人所提供的服务页面，就要求程序首先登录后再访问服务页面，这过程就需要自行处理cookie，想想当你用 java.net.HttpURLConnection来完成这些功能时是多么恐怖的事情啊！况且这仅仅是我们所说的顽固的WEB服务器中的一个很常见的 “顽固”！再有如通过HTTP来上传文件呢？不需要头疼，这些问题有了“它”就很容易解决了！

我们不可能列举所有可能的顽固，我们会针对几种最常见的问题进行处理。当然了，正如前面说到的，如果我们自己使用 java.net.HttpURLConnection来搞定这些问题是很恐怖的事情，因此在开始之前我们先要介绍一下一个开放源码的项目，这个项目就是 Apache开源组织中的httpclient，它隶属于Jakarta的commons项目，目前的版本是2.0RC2。commons下本来已经有一 个net的子项目，但是又把httpclient单独提出来，可见http服务器的访问绝非易事。

Commons-httpclient项目就是专门设计来简化HTTP客户端与服务器进行各种通讯编程。通过它可以 让原来很头疼的事情现在轻松的解决，例如你不再管是HTTP或者HTTPS的通讯方式，告诉它你想使用HTTPS方式，剩下的事情交给 httpclient替你完成。本文会针对我们在编写HTTP客户端程序时经常碰到的几个问题进行分别介绍如何使用httpclient来解决它们，为了 让读者更快的熟悉这个项目我们最开始先给出一个简单的例子来读取一个网页的内容，然后循序渐进解决掉前进中的所形侍狻?/font>

1． 读取网页(HTTP/HTTPS)内容

下面是我们给出的一个简单的例子用来访问某个页面

/*

 * Created on 2003-12-14 by Liudong

 */

package http.demo;

import java.io.IOException;

import org.apache.commons.httpclient.*;

import org.apache.commons.httpclient.methods.*;

/**

 * 最简单的HTTP客户端,用来演示通过GET或者POST方式访问某个页面

 * @author Liudong

 */

public class SimpleClient {

    public static void main(String[] args) throws IOException

    {

        HttpClient client = new HttpClient();   

        //设置代理服务器地址和端口    

        //client.getHostConfiguration().setProxy("proxy_host_addr",proxy_port);

        //使用GET方法，如果服务器需要通过HTTPS连接，那只需要将下面URL中的http换成https

        HttpMethod method = new GetMethod("http://java.sun.com");

        //使用POST方法

        //HttpMethod method = new PostMethod("http://java.sun.com");

        client.executeMethod(method);

        //打印服务器返回的状态

        System.out.println(method.getStatusLine());

        //打印返回的信息

        System.out.println(method.getResponseBodyAsString());

        //释放连接

        method.releaseConnection();

    }
}

在这个例子中首先创建一个HTTP客户端(HttpClient)的实例，然后选择 提交的方法是GET或者POST，最后在HttpClient实例上执行提交的方法，最后从所选择的提交方法中读取服务器反馈回来的结果。这就是使用 HttpClient的基本流程。其实用一行代码也就可以搞定整个请求的过程，非常的简单！

2． 以GET或者POST方式向网页提交参数

其实前面一个最简单的示例中我们已经介绍了如何使用GET或者POST方式来请求一 个页面，本小节与之不同的是多了提交时设定页面所需的参数，我们知道如果是GET的请求方式，那么所有参数都直接放到页面的URL后面用问号与页面地址隔 开，每个参数用&隔开，例如：http://java.sun.com?name=liudong&mobile=123456，但是当使用POST方法时就会稍微有一点点麻烦。本小节的例子演示向如何查询手机号码所在的城市，代码如下：

/*

 * Created on 2003-12-7 by Liudong

 */

package http.demo;

import java.io.IOException;

import org.apache.commons.httpclient.*;

import org.apache.commons.httpclient.methods.*;

/**

 * 提交参数演示

 * 该程序连接到一个用于查询手机号码所属地的页面

 * 以便查询号码段1330227所在的省份以及城市

 * @author Liudong

 */

public class SimpleHttpClient {

    public static void main(String[] args) throws IOException

    {

        HttpClient client = new HttpClient();

        client.getHostConfiguration().setHost("www.imobile.com.cn", 80, "http");

        HttpMethod method = getPostMethod();//使用POST方式提交数据

        client.executeMethod(method);

       //打印服务器返回的状态

        System.out.println(method.getStatusLine());

        //打印结果页面

        String response =

           new String(method.getResponseBodyAsString().getBytes("8859_1"));

       //打印返回的信息

        System.out.println(response);

        method.releaseConnection();

    }

    /**

     * 使用GET方式提交数据

     * @return

     */

    private static HttpMethod getGetMethod(){

        return new GetMethod("/simcard.php?simcard=1330227");

    }

    /**

     * 使用POST方式提交数据

     * @return

     */

    private static HttpMethod getPostMethod(){

        PostMethod post = new PostMethod("/simcard.php");

        NameValuePair simcard = new NameValuePair("simcard","1330227");

        post.setRequestBody(new NameValuePair[] { simcard});

        return post;

    }

}

在上面的例子中页面http://www.imobile.com.cn/simcard.php需要一个参数是simcard，这个参数值为手机号码段，即手机号码的前七位，服务器会返回提交的手机号码对应的省份、城市以及其他详细信息。GET的提交方法只需要在URL后加入参数信息，而POST则需要通过NameValuePair类来设置参数名称和它所对应的值

3． 处理页面重定向

在JSP/Servlet编程中response.sendRedirect方法就 是使用HTTP协议中的重定向机制。它与JSP中的<jsp:forward …>的区别在于后者是在服务器中实现页面的跳转，也就是说应用容器加载了所要跳转的页面的内容并返回给客户端；而前者是返回一个状态码，这些状态码 的可能值见下表，然后客户端读取需要跳转到的页面的URL并重新加载新的页面。就是这样一个过程，所以我们编程的时候就要通过 HttpMethod.getStatusCode()方法判断返回值是否为下表中的某个值来判断是否需要跳转。如果已经确认需要进行页面跳转了，那么可 以通过读取HTTP头中的location属性来获取新的地址。

状态码
 对应HttpServletResponse的常量
 详细描述
 
301
 SC_MOVED_PERMANENTLY
 页面已经永久移到另外一个新地址
 
302
 SC_MOVED_TEMPORARILY
 页面暂时移动到另外一个新的地址
 
303
 SC_SEE_OTHER
 客户端请求的地址必须通过另外的URL来访问
 
307
 SC_TEMPORARY_REDIRECT
 同SC_MOVED_TEMPORARILY
 

下面的代码片段演示如何处理页面的重定向

client.executeMethod(post);

        System.out.println(post.getStatusLine().toString());

        post.releaseConnection();

        //检查是否重定向

        int statuscode = post.getStatusCode();

        if ((statuscode == HttpStatus.SC_MOVED_TEMPORARILY) ||

            (statuscode == HttpStatus.SC_MOVED_PERMANENTLY) ||

            (statuscode == HttpStatus.SC_SEE_OTHER) ||

(statuscode == HttpStatus.SC_TEMPORARY_REDIRECT)) {

//读取新的URL地址

            Header header = post.getResponseHeader("location");

            if (header != null) {

                String newuri = header.getValue();

                if ((newuri == null) || (newuri.equals("")))

                    newuri = "/";

                GetMethod redirect = new GetMethod(newuri);

                client.executeMethod(redirect);

                System.out.println("Redirect:"+ redirect.getStatusLine().toString());

                redirect.releaseConnection();

            } else

                System.out.println("Invalid redirect");

        }

我们可以自行编写两个JSP页面，其中一个页面用response.sendRedirect方法重定向到另外一个页面用来测试上面的例子。

4． 模拟输入用户名和口令进行登录

本小节应该说是HTTP客户端编程中最常碰见的问题，很多网站的内容都只是对注册用 户可见的，这种情况下就必须要求使用正确的用户名和口令登录成功后，方可浏览到想要的页面。因为HTTP协议是无状态的，也就是连接的有效期只限于当前请 求，请求内容结束后连接就关闭了。在这种情况下为了保存用户的登录信息必须使用到Cookie机制。以JSP/Servlet为例，当浏览器请求一个 JSP或者是Servlet的页面时，应用服务器会返回一个参数，名为jsessionid（因不同应用服务器而异），值是一个较长的唯一字符串的 Cookie，这个字符串值也就是当前访问该站点的会话标识。浏览器在每访问该站点的其他页面时候都要带上jsessionid这样的Cookie信息， 应用服务器根据读取这个会话标识来获取对应的会话信息。

对于需要用户登录的网站，一般在用户登录成功后会将用户资料保存在服务器的会话中， 这样当访问到其他的页面时候，应用服务器根据浏览器送上的Cookie中读取当前请求对应的会话标识以获得对应的会话信息，然后就可以判断用户资料是否存 在于会话信息中，如果存在则允许访问页面，否则跳转到登录页面中要求用户输入帐号和口令进行登录。这就是一般使用JSP开发网站在处理用户登录的比较通用 的方法。

这样一来，对于HTTP的客户端来讲，如果要访问一个受保护的页面时就必须模拟浏览 器所做的工作，首先就是请求登录页面，然后读取Cookie值；再次请求登录页面并加入登录页所需的每个参数；最后就是请求最终所需的页面。当然在除第一 次请求外其他的请求都需要附带上Cookie信息以便服务器能判断当前请求是否已经通过验证。说了这么多，可是如果你使用httpclient的话，你甚 至连一行代码都无需增加，你只需要先传递登录信息执行登录过程，然后直接访问想要的页面，跟访问一个普通的页面没有任何区别，因为类HttpClient 已经帮你做了所有该做的事情了，太棒了！下面的例子实现了这样一个访问的过程。

/*

 * Created on 2003-12-7 by Liudong

 */

package http.demo;

import org.apache.commons.httpclient.*;

import org.apache.commons.httpclient.cookie.*;

import org.apache.commons.httpclient.methods.*;

/**

 * 用来演示登录表单的示例

 * @author Liudong

 */

public class FormLoginDemo {

    static final String LOGON_SITE = "localhost";

    static final int    LOGON_PORT = 8080;

    public static void main(String[] args) throws Exception{

        HttpClient client = new HttpClient();

        client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT);

       //模拟登录页面login.jsp->main.jsp

        PostMethod post = new PostMethod("/main.jsp");

        NameValuePair name = new NameValuePair("name", "ld");    

        NameValuePair pass = new NameValuePair("password", "ld");    

        post.setRequestBody(new NameValuePair[]{name,pass});

       int status = client.executeMethod(post);

        System.out.println(post.getResponseBodyAsString());

        post.releaseConnection(); 

       //查看cookie信息

        CookieSpec cookiespec = CookiePolicy.getDefaultSpec();

        Cookie[] cookies = cookiespec.match(LOGON_SITE, LOGON_PORT, "/", false, client.getState().getCookies());

       if (cookies.length == 0) {

           System.out.println("None");   

       } else {

           for (int i = 0; i < cookies.length; i++) {

               System.out.println(cookies[i].toString());   

           }

       }

       //访问所需的页面main2.jsp

        GetMethod get = new GetMethod("/main2.jsp");

        client.executeMethod(get);

        System.out.println(get.getResponseBodyAsString());

        get.releaseConnection();

    }

}

5． 提交XML格式参数

提交XML格式的参数很简单，仅仅是一个提交时候的ContentType问题，下面的例子演示从文件文件中读取XML信息并提交给服务器的过程，该过程可以用来测试Web服务。

import java.io.File;

import java.io.FileInputStream;

import org.apache.commons.httpclient.HttpClient;

import org.apache.commons.httpclient.methods.EntityEnclosingMethod;

import org.apache.commons.httpclient.methods.PostMethod;

/**

 * 用来演示提交XML格式数据的例子

 */

public class PostXMLClient {

    public static void main(String[] args) throws Exception {

        File input = new File(“test.xml”);

        PostMethod post = new PostMethod(“http://localhost:8080/httpclient/xml.jsp”);

        // 设置请求的内容直接从文件中读取

        post.setRequestBody(new FileInputStream(input));

        if (input.length() < Integer.MAX_VALUE)

            post.setRequestContentLength(input.length());

        else            post.setRequestContentLength(EntityEnclosingMethod.CONTENT_LENGTH_CHUNKED);

        // 指定请求内容的类型

        post.setRequestHeader("Content-type", "text/xml; charset=GBK");

        HttpClient httpclient = new HttpClient();

        int result = httpclient.executeMethod(post);

        System.out.println("Response status code: " + result);

        System.out.println("Response body: ");

        System.out.println(post.getResponseBodyAsString());

        post.releaseConnection();

    }

}

6． 通过HTTP上传文件

httpclient使用了单独的一个HttpMethod子类来处理文件的上传，这个类就是MultipartPostMethod，该类已经封装了文件上传的细节，我们要做的仅仅是告诉它我们要上传文件的全路径即可，下面的代码片段演示如何使用这个类。

MultipartPostMethod filePost = new MultipartPostMethod(targetURL);

filePost.addParameter("fileName", targetFilePath);

HttpClient client = new HttpClient();

//由于要上传的文件可能比较大,因此在此设置最大的连接超时时间

client.getHttpConnectionManager().getParams().setConnectionTimeout(5000);

int status = client.executeMethod(filePost);

上面代码中，targetFilePath即为要上传的文件所在的路径。

7． 访问启用认证的页面

我们经常会碰到这样的页面，当访问它的时候会弹出一个浏览器的对话框要求输入用户名 和密码后方可，这种用户认证的方式不同于我们在前面介绍的基于表单的用户身份验证。这是HTTP的认证策略，httpclient支持三种认证方式包括： 基本、摘要以及NTLM认证。其中基本认证最简单、通用但也最不安全；摘要认证是在HTTP 1.1中加入的认证方式，而NTLM则是微软公司定义的而不是通用的规范，最新版本的NTLM是比摘要认证还要安全的一种方式。

下面例子是从httpclient的CVS服务器中下载的，它简单演示如何访问一个认证保护的页面：

import org.apache.commons.httpclient.HttpClient;

import org.apache.commons.httpclient.UsernamePasswordCredentials;

import org.apache.commons.httpclient.methods.GetMethod;

public class BasicAuthenticationExample {

    public BasicAuthenticationExample() {

    }

    public static void main(String[] args) throws Exception {

        HttpClient client = new HttpClient();

        client.getState().setCredentials(

            "www.verisign.com",

            "realm",

            new UsernamePasswordCredentials("username", "password")

        );

        GetMethod get = new GetMethod("https://www.verisign.com/products/index.html");

        get.setDoAuthentication( true );

        int status = client.executeMethod( get );

        System.out.println(status+""+ get.getResponseBodyAsString());

        get.releaseConnection();

    }

}

8． 多线程模式下使用httpclient

多线程同时访问httpclient，例如同时从一个站点上下载多个文件。对于同一 个HttpConnection同一个时间只能有一个线程访问，为了保证多线程工作环境下不产生冲突，httpclient使用了一个多线程连接管理器的 类：MultiThreadedHttpConnectionManager，要使用这个类很简单，只需要在构造HttpClient实例的时候传入即 可，代码如下：

MultiThreadedHttpConnectionManager connectionManager =

   new MultiThreadedHttpConnectionManager();

HttpClient client = new HttpClient(connectionManager);

以后尽管访问client实例即可。

参考资料：