JEP 110: New HTTP Client
|Discussion||net dash dev at openjdk dot java dot net|
We would like to define and implement a new HTTP client API to replace the legacy HttpURLConnection and which leverages the new features of NIO (non-blocking & asynchronous I/O).
Existing URLConnection based API was designed with multiple protocols in mind, nearly all of which are defunct now (ftp, gopher, etc.)
Existing API not flexible enough
Hard to use (much behavior undocumented)
Unperformant (1 thread per request, blocking)
Very hard to maintain
Need asynchronous and possibly non-blocking API
Need request/response lifecycle interception, specially for internal Implementation
Need different providers (implementations)
Other general requirements:
Must expose all relevant aspects off the HTTP protocol request to a server and response from a server (headers, body, status codes etc)
Must be simple to use
Must include Java EE standard authentication mechanisms and allow for other schemes
Must do request/response filtering
Must be able to intercept HTTP request/response completion lifecycle events (headers sent, body sent, headers received, body available etc)
Must work well as a base for the JAX-RS Client API
Must be able to easily set up the web sockets handshake
Separate request/response (like servlet and http server API)
Integrate with NIO, ie. should work with selectors or asynchronously
An asynchronous send of a HttpRequest should return a Future<HttpResponse>
Alternatively an asynchronous send could provide a CompletionHandler<HttpResponse,HttpRequest~> to be invoked when the request completed.
A non-blocking send would be given a Selector to register with and return a SelectionKey. A method on HttpRequest would then be called to handle Selector activity and eventually return a HttpResponse.
Standalone, ie. existing stack will be left as is to ensure compatibility and allow a phased approach (don’t have to support everything at once)
Modular, ie. may have to exist in own module (or distinct from core)
Features that have to be supportable (if not supported initially)
- https via SSLEngine
Should be extensible through “filter” type mechanism (like servlet, http server). many of the features above will be implemented as filter modules.
A number of existing HTTP client API and implementations exist - two notable ones are Jetty (org.mortbay.jetty) and the Apache HTTP client.
Both of these were designed prior to NIO and are both rather heavy-weight in terms of numbers of packages and classes. However, some recent work has been done on an API which provides a similar asynchronous mode of operation (based on NIO). We should see what/if any part of this work we can adopt.
Will need new tests. The internal http server will provide a suitable test harness for regression tests and TCK tests. SQE tests could use it also, but may need to test against real http servers.
- Other JDK components: no impact
- Compatibility: no impact
- Security: no impact
- Portability: no impact
- User Interface: no impact
- Documentation: no impact
- Internationalization: no impact
- Localization: no impact
- Legal: no impact
- Other: no impact