A Comparison of Java - net.URLConnection and HTTPClient

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 1

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 Methods Only HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS. HTTPClient Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method, such as those from WEBDav and IPP.

The response code, headers, and body can only be read if The response code, all headers, and the response code was less than 400 - for any 4xx or 5xx the body can always be read Response Codes response code, you only get IOException's when trying to normally. get any response info. Proxies and SOCKS Full support (SOCKS: Version 4 only) 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. No. No - all data is fully buffered before it is sent. Full support (SOCKS: both version 4 and 5) Support for Basic and Digest Authentication; other schemes can be added. Yes. Yes - HttpOutputStream will stream directly to the socket.

Authorization

Cookies True request output streams True response input streams Persistent Connections Pipelining of Requests Can handle protocols other than HTTP

Under JDK 1.2, yes; under JDK 1.3 only if the response is not sent using the chunked encoding (this excludes most Yes. server-push responses). HTTP/1.0 Keep-Alive's in JDK 1.1 and JDK 1.2; JDK 1.3 Supports HTTP/1.0 Keep-Alive's has HTTP/1.1 persistence. and HTTP/1.1 persistence. No. Yes. Yes. No.

Can set Timeouts No. Yes (e.g. ftp, gopher, mailto, and file are provided)

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

You might also like