The pre-Java 9 HTTP client

JDK version 1.1 introduced the HttpURLConnection API that supported HTTP-specific features. This was a robust class that included the following fields:

  • chunkLength
  • fixedContentLength
  • fixedContentLengthLong
  • HTTP_ACCEPTED
  • HTTP_BAD_GATEWAY
  • HTTP_BAD_METHOD
  • HTTP_BAD_REQUEST
  • HTTP_CLIENT_TIMEOUT
  • HTTP_CONFLICT
  • HTTP_CREATED
  • HTTP_ENTITY_TOO_LARGE
  • HTTP_FORBIDDEN
  • HTTP_GONE
  • HTTP_INTERNAL_ERROR
  • HTTP_LENGTH_REQUIRED
  • HTTP_MOVED_PERM
  • HTTP_MOVED_TEMP
  • HTTP_MULT_CHOICE
  • HTTP_NO_CONTENT
  • HTTP_NOT_ACCEPTABLE
  • HTTP_NOT_AUTHORITATIVE
  • HTTP_NOT_FOUND
  • HTTP_NOT_IMPLEMENTED
  • HTTP_NOT_MODIFIED
  • HTTP_OK
  • HTTP_PARTIAL
  • HTTP_PAYMENT_REQUIRED
  • HTTP_PRECON_FAILED
  • HTTP_PROXY_AUTH
  • HTTP_REQ_TOO_LONG
  • HTTP_RESET
  • HTTP_SEE_OTHER
  • HTTP_SERVER_ERROR
  • HTTP_UNAUTHORIZED
  • HTTP_UNAVAIABLE
  • HTTP_UNSUPPORTED_TYPE
  • HTTP_USE_PROXY
  • HTTP_VERSION
  • instanceFollowRedirects
  • method
  • responseCode
  • responseMessage

 

As you can see from the preceding list of fields, there was already great support for HTTP. In addition to a constructor, there are a plethora of available methods, including the following:

  • disconnect()
  • getErrorStream()
  • getFollowRedirects()
  • getHeaderField(int n)
  • getHeaderFieldDate(String name, long Default)
  • getHeaderFieldKey(int n)
  • getInstanceFollowRedirects()
  • getPermission()
  • getRequestMethod()
  • getResponseCode()
  • getResponseMessage()
  • setChunkedStreamingMode(int chunklen)
  • setFixedLengthStreamingMode(int contentLength)
  • setFixedlengthStreamingMode(long contentLength)
  • setFollowRedirects(boolean set)
  • setInstanceFollowRedircts(boolean followRedirects)
  • setRequestMethod(String method)
  • usingProxy()

The class methods listed earlier are in addition to the methods inherited from the java.net.URLConnection class and the java.lang.Object class.

There were problems with the original HTTP client that made it ripe for updating with the new Java platform. Those problems were as follows:

  • The base URLConnection API had defunct protocols such as Gopher and FTP becoming an increasing issue over the years
  • The HttpURLConnection API predated HTTP 1.1 and was overly abstract, making it less usable
  • The HTTP client was woefully under documented, making the API frustrating and difficult to use
  • The client only functioned on one thread at a time
  • The API was extremely difficult to maintain due to it predating HTTP 1.1 and lacking sufficient documentation

Now that we know what was wrong with the previous HTTP client, let's look at the current HTTP client.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset