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