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).