A Comparison of java.net.URLConnection and HTTPClient

Since java.net.URLConnection and HTTPClient have overlapping functionalities, the question arises of why would you use HTTPClient. Here are a few of the capabilites and tradeoffs.

Note that if you're running an applet, then things depend on which browser you're running under, as the browser provides the actual client implementation used by URLConnection; therefore the following just lists the differences as compared to Sun's http client (which is the default client used by URLConnection in applications).

URLConnection

HTTPClient

Methods

Only HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS.
Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method, such as those from WEBDav and IPP.
Response Codes

The response code, headers, and body can only be read if the response code was less than 400 - for any 4xx or 5xx response code, you only get IOException's when trying to get any response info.
The response code, all headers, and the body can always be read normally.
Proxies and SOCKS

Full support (SOCKS: Version 4 only)
Full support (SOCKS: both version 4 and 5)
Authorization

Support for Basic and an early version of Digest in JDK 1.2 or later, only. The current version of Digest authentication (which is the one supported by most servers) is not supported, and due to a bug of theirs they won't even recognize the digest info returned by Apache.
Support for Basic and Digest Authentication; other schemes can be added.
Cookies

No.
Yes.
True request output streams

No - all data is fully buffered before it is sent.
Yes - HttpOutputStream will stream directly to the socket.
True response input streams

Under JDK 1.2, yes; under JDK 1.3 only if the response is not sent using the chunked encoding (this excludes most server-push responses).
Yes.
Persistent Connections

HTTP/1.0 Keep-Alive's in JDK 1.1 and JDK 1.2; JDK 1.3 has HTTP/1.1 persistence.
Supports HTTP/1.0 Keep-Alive's and HTTP/1.1 persistence.
Pipelining of Requests

No.
Yes.
Can set Timeouts

No.
Yes.
Can handle protocols other than HTTP

Yes (e.g. ftp, gopher, mailto, and file are provided)
No.
Can do HTTP over SSL (https)

Appropriate SSL package (such as JSSE) which provides an appropriate client must be installed.
Patches are available for various free and commercial SSL packages
Source code available

No.
Yes.

	URLConnection	HTTPClient
Methods	Only HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS.	Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method, such as those from WEBDav and IPP.
Response Codes	The response code, headers, and body can only be read if the response code was less than 400 - for any 4xx or 5xx response code, you only get IOException's when trying to get any response info.	The response code, all headers, and the body can always be read normally.
Proxies and SOCKS	Full support (SOCKS: Version 4 only)	Full support (SOCKS: both version 4 and 5)
Authorization	Support for Basic and an early version of Digest in JDK 1.2 or later, only. The current version of Digest authentication (which is the one supported by most servers) is not supported, and due to a bug of theirs they won't even recognize the digest info returned by Apache.	Support for Basic and Digest Authentication; other schemes can be added.
Cookies	No.	Yes.
True request output streams	No - all data is fully buffered before it is sent.	Yes - HttpOutputStream will stream directly to the socket.
True response input streams	Under JDK 1.2, yes; under JDK 1.3 only if the response is not sent using the chunked encoding (this excludes most server-push responses).	Yes.
Persistent Connections	HTTP/1.0 Keep-Alive's in JDK 1.1 and JDK 1.2; JDK 1.3 has HTTP/1.1 persistence.	Supports HTTP/1.0 Keep-Alive's and HTTP/1.1 persistence.
Pipelining of Requests	No.	Yes.
Can set Timeouts	No.	Yes.
Can handle protocols other than HTTP	Yes (e.g. ftp, gopher, mailto, and file are provided)	No.
Can do HTTP over SSL (https)	Appropriate SSL package (such as JSSE) which provides an appropriate client must be installed.	Patches are available for various free and commercial SSL packages
Source code available	No.	Yes.

Ronald Tschalär / 6. May 2001 / ronald@innovation.ch.