httpClient-3.1 Study Notes

Http://hc.apache.org/httpclient-3.x/tutorial.html
The general process for using HttpClient consists of a number of steps:

Create an instance of HttpClient.
Create an instance of one of the methods (GetMethod in this case). The URL to connect to was passed in to the method constructor.
Tell HttpClient to execute the method.
Read the response.
Release the connection.
Deal with the response.
The httpclient can be verified with the server automatically, but the developer needs to provide the credentials required for httpclient verification, which is stored in httpstate. Httpstate instance can be SetCredentials (authscope authscope, Credentials cred) and getcredentials (Authscope authscope) To get and set. Automatic validation in httpclient can only be canceled by HttpMethod, which is limited to this method.setdoauthentication (Boolean doauthentication)
When validation is not explicitly specified, host sends out the validation information for default. So when we visit an untrusted website, we don't want to send credentials's message, So we set the range of sending credentials in HttpClient. The following settings are not recommended for any site that has credentials information.
To is avoided unless in debug mode
Credentials defaultcreds = new Usernamepasswordcredentials ("username", "password");
Client.getstate (). SetCredentials (Authscope.any, defaultcreds);
Authentication with the agent is the same as the validation of the server, but there are separate settings and methods for obtaining validation:
Etproxycredentials (Authscope authscope, Credentials cred) and getproxycredentials (Authscope authscope).
HttpClient supported authentication scheme:basic, Digest, NTLM
1.basic scheme is the most basic, but also the best compatibility, but also the most insecure, its problem is that it transmits the user name and password, the time is not encrypted. When using this mode, Must be shown to provide or use the default Usernamepasswordcredentials
2.Digest is safe, it is through the client to the server sent back a value of a nonce to encrypt, and then sent back, will not send the password. The problem with it is that It may not be very good to be supported by HTTP. It also needs to be shown to provide or use the default Usernamepasswordcredentials
3.NTLM is a set of proven methods developed by Microsoft, which is fixed in Windows NT4. NTLM authentication requires a ntcredentials for the domain name that is required, or a default credentials. There are some differences between using NTLM and using the other two authentication methods:
A. You need to provide ntcredentials instead of usernamepasswordcredentials.
B. In NTLM authentication realm is the domain name of the computer you are connected to, so there is a problem when there is more than one domain name for a computer. The domain that owns the httpclient connection Name will look for the corresponding credentials. (as specified by the hostconfiguration). It is generally advised and initially testing NTLM authentication, you pass the realm as null which are used as T He default.
C.NTLM is a connection and not a request, so it needs to be verified each time a new connection is opened. Therefore, NTLM is not supported in HTTP 1.0
We can provide httpclient with a variety of authentication scheme, but HttpClient will choose one of them when it is actually validated. The default three scheme has a certain priority: Ntlm,digest,basic
The default preference of the authentication schemes may be altered using the ' http.auth.scheme-priority ' parameter. The parameter value is expected to being a List of Strings containing names of authentication schemes in descending order of Preference.
HttpClient client = new HttpClient ();
List authprefs = new ArrayList (2);
Authprefs.add (authpolicy.digest);
Authprefs.add (Authpolicy.basic);
This would exclude the NTLM authentication scheme
Client.getparams (). Setparameter (authpolicy.auth_scheme_priority, authprefs);
In addition to the above three HTTP self-sustaining authentication methods, HttpClient also supports the Customed authentication method, as long as

1.Implement the Authscheme interface.
2.Register the custom Authscheme with Authpolicy.registerauthscheme ().
3.Include the custom authscheme in the Authpolicy.auth_scheme_priority preference (see the Alternate authentication Sectio N).
public class Basicauthenticationexample {
46
47/**
* Constructor for Basicauthenticatonexample.
49 */
Public Basicauthenticationexample () {
Wuyi super ();
52}
53
Wu public static void Main (string[] args) throws Exception {
HttpClient client = new HttpClient ();
56
//Pass our credentials to HttpClient, they'll only is used for
+//authenticating to servers with realm ' realm ' on the host
//"www.verisign.com", to authenticate against
Arbitrary realm or host change the appropriate argument to NULL.
Client.getstate (). SetCredentials (
Authscope New ("www.verisign.com", 443, "realm"),
New Usernamepasswordcredentials ("username", "password")
64);
65
//Create a GET method that reads a file over HTTPS, we ' re assuming
*//That this file requires Basic authentication using the realm above.
GetMethod get = new GetMethod ("https://www.verisign.com/products/index.html");
69
The GET method to automatically handle authentication. The
//method would use any appropriate credentials to handle basic
Authentication//requests. Setting this value to false would cause
Authentication to return with a status of 401.
The handle//It'll then is up to the client to the authentication.
Get.setdoauthentication (TRUE);
76
try {
//Execute the GET
+ INT status = Client.executemethod (get);
80
Bayi//Print the status and response
SYSTEM.OUT.PRINTLN (status + "\ n" + get.getresponsebodyasstring ());
83
(+)} finally {
Connection resources used by the method
Get.releaseconnection ();
87}
88}
89}
The coding problem of httpclient mainly involves three aspects: header,body, and URL

Headers must be US-ASCLL encoded. Because the cookie is in the head, the cookie must also be encoded using US-ASCLL.
The code in the body can be any encoding, the default is Iso-8859-1, and its encoding can be specified in the Content-type.
content-type:text/html; Charset=utf-8
In this case, httpclient can safely use the UTF-8 encoding to convert the body to a string. You can set the Content-type in Requestheader by Addrequestheader
You can also get the response body encoding, using the Getresponsecharset method. If you determine that the returned result is a string, you can use the Getresponsebodyasstring method, He will automatically use the encoding set specified in Content-type to solve the character, if there is no Content-type header, will use the default encoding iso-8859-1
Note that a file, such as xml/html, allows the encoding of the specified file, in which case you will need to parse the file using the appropriate encoding, which may not be the same as the code specified in the response header.
The Url:url protocol explicitly specifies that the URL is encoded using US-ASCLL, and is defined in bytes. 16 characters are not in us-ascll, so some hexadecimal is prefixed with some controls. The characters in these ranges must be encoded. Characters that cannot be encoded using US-ASCLL cannot appear in the URL.
Despite this, some servers does support varying means of encoding double byte characters in URLs, the most common technique Seems to is to use UTF-8 encoding and encode each octet separately even if a pair of octets represents one character. This however, isn't specified by the standard and was highly prone to error, so it's recommended that URLs being restricted To the 8-bit ASCII range.
About Redirect: or read the original: http://hc.apache.org/httpclient-3.x/redirects.html feel no point. Primarily some redirected status 3XX, Take a look at the meaning of each status representation.
The exceptions you'll encounter with HttpClient include two exceptions: Transport exception, and protocol exception. Not all exceptions are thrown in httpclient, and some exceptions are handled internally.
Transport exception are caused by failures in input and output, which are generally due to unreliable network transmissions or timeouts in a single operation, such as the expiration of cookies. In general, the transport exception is not fatal, You can retry. But if an operation is not idempotent, you need to be aware of it.
The exception of the general transport is represented by the IOException or its subclasses such as socketexception,interruptedioexception. In addition to these standard input and output exceptions, HttpClient also customizes some transport exception exceptions.
Java.io.IOException
+-Org.apache.commons.httpclient.NoHttpResponseException
Nohttpresponceexception: This exception is due to the fact that when the client throws too many exceptions to the server, the server may not be able to afford it, so the servers will accept the request, but will not make response. This is the time to throw this exception. , you can reduce the speed at which the request is made, and then retry.
Java.io.IOException
+-Java.io.InterruptedIOException
+-Org.apache.commons.httpclient.ConnectTimeoutException
Org.apache.commons.httpclient.ConnectTimeoutException: This exception indicates that httpclient cannot establish a connection with serve or proxy, and in a certain amount of time, it is timed out.
Java.io.IOException
+-Java.io.InterruptedIOException
+-Org.apache.commons.httpclient.ConnectTimeoutException
+-Org.apache.commons.httpclient.ConnectionPoolTimeoutException
This exception occurs only when using Multithreaded Connection Manager, which indicates that a connection management cannot get an idle connection in the connection pool for a certain amount of time.
Java.io.IOException
+-Org.apache.commons.httpclient.HttpException
+-Org.apache.commons.httpclient.HttpRecoverableException
This exception has now been deprecated and will no longer be thrown in the standard httpclient classes and methods.
Protocol exception. Usually the mismatch between the server (target server or proxy server) and the client, so when this exception occurs, you need to modify some information about the request that occurred.
Java.io.IOException
+-Org.apache.commons.httpclient.HttpException
This exception represents an error that is caused by this logical mismatch. The request information is generally required to be modified.
Java.io.IOException
+-Org.apache.commons.httpclient.HttpException
+-Org.apache.commons.httpclient.ProtocolException
Protocolexception signals a violation of the HTTP specification. It's important to note the HTTP proxies and HTTP servers can has different level of HTTP specification compliance. It May is possible to recover from some HTTP protocol exceptions by configuring HttpClient to being more lenient about NON-FA TAL protocol violations.
There are other exceptions that are handled internally, including errors in the validation operation: The authentication configuration file cannot be found, validation errors, authentication denied, cookie errors, illegal redirect,uri that occur when the redirect is automatically processed, and so on.
HTTP is stateless, so be aware of the power of HTTP requests.
There are a few exceptions, and HttpClient will try to recover after snapping. HttpClient will not exception to protocol. Transport will automatically repeat up to 5 operations when the httpclient exception occurs. To try to recover. Or if your request hits the server, the server does not return to status, which means that the server may have lost the request. If this is the case, some applications or server status may change, It is better for us to customize the methods internally to handle these exceptions.
If you want to customize the method for handling internal exceptions, you need to implement Httpmethodretryhandler and then Setparameter in HttpMethod to specify which retry_handler to use;
HttpClient client = new HttpClient ();

Httpmethodretryhandler Myretryhandler = new Httpmethodretryhandler () {
public Boolean Retrymethod (
Final HttpMethod method,
Final IOException exception,
int Executioncount) {
if (Executioncount >= 5) {
Do not retry if-over Max retry count
return false;
}
If (Exception instanceof Nohttpresponseexception) {
Retry if the server dropped connection on us
return true;
}
if (!method.isrequestsent ()) {
Retry If the request has a not been sent fully or
If it's OK to retry methods that has been sent
return true;
}
Otherwise do not retry
return false;
}
};

GetMethod httpget = new GetMethod ("http://www.whatever.com/");
Httpget.getparams ().
Setparameter (Httpmethodparams.retry_handler, Myretryhandler);
try {
Client.executemethod (HttpGet);
System.out.println (Httpget.getstatusline (). toString ());
} finally {
Httpget.releaseconnection ();
}

About HttpClient log, which uses the common log, we can use the other log implementations at the bottom. HttpClient performs-different kinds of logging:the standard context logging used within each class, and wire logging.

httpClient-3.1 Study Notes