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.

	URLConnection	HTTPClient
Proxies and SOCKS	Full support in Netscape browser, appletviewer, and applications (SOCKS: Version 4 only); no additional limitations from security policies.	Full support (SOCKS: Version 4 and 5); limited in applets however by security policies; in Netscape can't pick up the settings from the browser.
Authorization	Full support for Basic Authorization in Netscape (can use info given by the user for normal accesses outside of the applet); no support in appletviewer or applications.	Full support everywhere; however cannot access previously given info from Netscape, thereby possibly requesting the user to enter info (s)he has already given for a previous access. Also, you can add/implement additional authentication mechanisms yourself.
Methods	Only has GET and POST.	Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method.
Headers	Currently you can only set any request headers if you are doing a POST under Netscape; for GETs and the JDK you can't set any headers. Under Netscape 3.0 you can read headers only if the resource was returned with a Content-length header; if no Content-length header was returned, or under previous versions of Netscape, or using the JDK no headers can be read.	Allows any arbitrary headers to be sent and received.
Automatic Redirection Handling	Yes.	Yes (as allowed by the HTTP/1.1 spec).
Persistent Connections	No support currently in JDK; under Netscape uses HTTP/1.0 Keep-Alive's.	Supports HTTP/1.0 Keep-Alive's and HTTP/1.1 persistence.
Pipelining of Requests	No.	Yes.
Can handle protocols other than HTTP	Theoretically; however only http is currently implemented.	No.
Can do HTTP over SSL (https)	Under Netscape, yes. Using Appletviewer or in an application, no.	No (not yet).
Source code available	No.	Yes.