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

Methods

JDK 1.0.2: Only has GET and POST.
JDK 1.1: HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS
Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method.
Headers

You can only set request headers if you are using JDK 1.1 or doing a POST under Netscape; for GETs in Netscape and when using JDK 1.0.2 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 1.0.2 no headers can be read. All headers can be read in JDK 1.1.
Allows any arbitrary headers to be sent and received.
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 Authentication in Netscape (can use info given by the user for normal accesses outside of the applet); no support in appletviewer or applications.
Support for Basic and Digest Authentication; other schemes can be added. However cannot access info from a browser, thereby possibly requiring the user to enter info (s)he has already given for a previous access.
Automatic Redirection Handling

Yes.
Yes (as allowed by the HTTP/1.1 spec).
Cookies

No.
Yes.
Persistent Connections

HTTP/1.0 Keep-Alive's in JDK 1.1 and under Netscape; no persistence in JDK 1.0.2.
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.

	URLConnection	HTTPClient
Methods	JDK 1.0.2: Only has GET and POST. JDK 1.1: HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS	Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method.
Headers	You can only set request headers if you are using JDK 1.1 or doing a POST under Netscape; for GETs in Netscape and when using JDK 1.0.2 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 1.0.2 no headers can be read. All headers can be read in JDK 1.1.	Allows any arbitrary headers to be sent and received.
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 Authentication in Netscape (can use info given by the user for normal accesses outside of the applet); no support in appletviewer or applications.	Support for Basic and Digest Authentication; other schemes can be added. However cannot access info from a browser, thereby possibly requiring the user to enter info (s)he has already given for a previous access.
Automatic Redirection Handling	Yes.	Yes (as allowed by the HTTP/1.1 spec).
Cookies	No.	Yes.
Persistent Connections	HTTP/1.0 Keep-Alive's in JDK 1.1 and under Netscape; no persistence in JDK 1.0.2.	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.

Ronald Tschalär / 30. January 1998 / ronald@innovation.ch.