Is there much difference between those two and which one is preferably to use?
Based on the Android source code:
https://github.com/CyanogenMod/android_frameworks_base/blob/gingerbread/core/java/android/net/http/AndroidHttpClient.java#L106
AndroidHttpClient is set to do the following extra settings:
Turn off stale checking, since the connections can break all the time.
Set ConnectionTimeout and SoTimeout (20 or 60 seconds)
Turn off redirecting.
Use a session cache for SSL sockets.
Use gzip compressed traffic between client and server if it's possible.
Doesn't retain cookies by default.
AndroidHttpClient: Subclass of the Apache DefaultHttpClient that is configured with reasonable default settings and registered schemes for Android, and also lets the user add HttpRequestInterceptor classes.
This client processes cookies but does not retain them by default. To retain cookies, simply add a cookie store to the HttpContext
[API]
This interesting blog post from an android developer gives an overview of the different Android’s HTTP clients.
According to this post, URLConnection should be preferred over DefaultHttpClient or AndroidHttpClient on Gingerbread and above.
Related
I am downloading gigabytes of data (a large number of small files) at a time and would like to optimize the download times by instead using a HTTP request instead of using HTTPS, which is a slower process, especially if repeated thousands of times before each transfer.
What is the default request protocol for the Java AWS SDK and how can I set it to HTTP?
When constructing a client object (For example AmazonEC2Client), you can pass in an optional com.amazonaws.ClientConfiguration object to customize the client's configuration.
Use the below constuctor:
AmazonEC2Client(AWSCredentials awsCredentials, ClientConfiguration clientConfiguration)
Read more here.
Now, while creating the ClientConfiguration object you can use setProtocol() to define the protocol to be HTTP or HTTPS. And accordingly the client object hence created would use that protocol. See here.
In building web service designed to to interact with mobile devices, I am not sure what the best approach is for implementing HTTP requests on Android.
I came across this post, which finishes by stating HttpURLConnection is the preferred method for making HTTP requests, and I have had success using the HttpsURLConnection.
When searching for answers or reading other sample code (even fairly recent posts), all seem to use DefaultHttpClient, which seems to go against the official word from Google.
I am trying to future proof my Android application as much as possible. With that in mind, is the HttpURLConnection the best choice?
If you are supporting 2.2 as well, Best approach may be to utilize both DefaultHttpClient or HttpURLConnection
if (Integer.parseInt(Build.VERSION.SDK) <= Build.VERSION_CODES.FROYO) {
// Use DefaultHttpClient here
}
else{
//use HttpURLConnection
}
Reason: HttpURLConnection is more stable after Froyo while DefaultHttpClient is less buggy in froyo and lesser version.
Ref : http://developer.android.com/reference/org/apache/http/impl/client/DefaultHttpClient.html
Android includes two HTTP clients: HttpURLConnection and Apache HTTP Client. Both support HTTPS, streaming uploads and downloads, configurable timeouts, IPv6 and connection pooling. Apache HTTP client has fewer bugs in Android 2.2 (Froyo) and earlier releases. For Android 2.3 (Gingerbread) and later, HttpURLConnection is the best choice. Its simple API and small size makes it great fit for Android. Transparent compression and response caching reduce network use, improve speed and save battery. See the Android Developers Blog for a comparison of the two HTTP clients.
It really matters which version of Android you are using. Take a look at http://android-developers.blogspot.com/2011/09/androids-http-clients.html for some guidance from Google.
DefaultHttpClient is at a higher level of abstraction than HttpUrlConnection. Either one should be fine based on your needs. If you dont need the control of HttpUrlConnection, stick with the DefaultHttpClient.
I want to create a small java application to copy some wiki content from one server to another. The API is based on the XML-RPC.
Basically I have three methods, login, getPage and putPage. I use Apache HttpClient 3.x and managed to use login to login successfully and getPage to get a page from the old wiki correctly.
Authentication is handled with cookies: I log into the new wiki and some cookies are set on the corresponding httpclient. The doku tells me that one of those cookies is used for authentification.
Then I execute putPage with another POST method on the same httpclient and the server responds with a authentication failure message.
The code sequence goes like this (very reduced):
HttpClient client = new HttpClient();
PostMethod postLogin = createNewPostMethod("login", "user", "pw");
client.executeMethod(postLogin);
// Now I'm logged in and the client definitly has stored the cookies
PostMethod postPutPage = createNewPostMethod("putPage", getPage());
client.executeMethod(postPutPage); // the server won't let me put the page
Should it work like that or do I have to add the cookies manually to the second post method and, if yes, how?
Edit / Solution
With the help of the answers to this question I was able to identify and solve the problem, which was outside of the usage of httpclient. At the end it was a configuration issue on the target wiki side. The answers here helped me to ask the right questions in another forum.
Cookies are handled by HTTPClient by default. You shouldn't have to do anything to have cookies work properly.
Source:
http://www.innovation.ch/java/HTTPClient/getting_started.html#cookies
Edit for Apache HTTP Client:
Apache HTTP Client behaves the same :-)
Here is the source:
http://hc.apache.org/httpclient-3.x/cookies.html
You can set manually cookies with HTTP Client but it will handle correctly cookies created during your connection.
HttpClient supports automatic management of cookies, including allowing the server to set cookies and automatically return them to the server when required. It is also possible to manually set cookies to be sent to the server.
Resources :
Apache HttpClient - cookies
I have historically used this when I wanted to accept cookies with HttpClient
postPutPage.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
When I Get "https://login.facebook.com" by using Chrome, the response is 302 and redirect me to http://www.facebook.com. However, when I get "https://login.facebook.com" by using HttpClient's GetMethod, it will be blocked for a long time and finally throws a Timeout Exception.
I feel really frustrating. Is the implementation of Sun JDK's SSL which HttpClient is based on not compatible with facebook's login server?
Can any one tell me what should I do to connect https://login.facebook.com by using HttpClient.
You should use the facebook api for java for doing so. I think they block requests like yours, since they have made an api for developers to log in through.
You need to join the facebook developers group and create an application so you can get an API key. Se link below for more information.
Download it here
When I access a HTTP server using the standard Java API (java.net.URLConnection), the credentials are "cached" after the first successful authentication, and subsequent calls to Authenticator.setDefault() have no effect. So, I need to restart the application in order to use different credentials.
I don't observe this effect when Basic Authentication is used. But I need to use NTLM for the server I'm accessing, and the Jakarta Commons HttpClient isn't an alternative either because it doesn't support NTLMv2 (see http://oaklandsoftware.com/papers/ntlm.html)
Looking at the packets using Wireshark, I also observe that before the first successful authentication, an authentication with the current Windows credentials is attempted first. But after succesful authentication, only the saved credentials are used.
Is there any way to reset or change the credentials java.net.Authenticator is using after a successful NTLM authentication?
Nope
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6626700
indicates this is an outstanding bug. An author in there suggests some nasty reflection magic to get past this. That's ok as long as this is in-house and documented as fragile and potentially breaking. Certainly not great
Would HttpClient 4.x + jCIFS 1.3.x be an alternative?