Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8186829

HTTP Client impl - Reduce implementation execution modes



      The API supports both synchronous and asynchronous modes of operation. This is fine, and will remain. The implementation, however, has three separate modes of operation when reading / writing to the underlying socket: 1) blocking, 2) non-blocking, and 3) asynchronous. These modes are currently necessary as the HTTP/1.1 implementation is blocking ( the request is sent blocking, socket switched to non-blocking and registered with a selector, upon read-ready switched back to blocking and the response is read blocking ). The HTTP/2 implementation is completely async. The blocking mode causes a proliferation of connection types as well as duplication of all code connected with reading and writing. This is further complicated as connections may start off as HTTP/1.1 and then be upgraded to HTTP/2, thus requiring switching out the connection type and protocol coder / decoder. A "fake" HTTP/1.1 initial upgrade request cannot be made as 1) the connection may not actually be upgraded, and 2) redirection, authentication, proxying support, is required at this point ( do not want to duplicate this ).

      A single execution mode ( event-driven non-blocking ) in the implementation will significantly reduce the amount of code, while increasing the common machinery that can be shared across HTTP/1.1 and HTTP/2. The synchronous mode of operation in the API will be implemented trivially as a join on an async call.

      Note: since HTTP/1.1 is currently implemented as blocking, there is no non-blocking support for parsing headers or chunked encoding. This will be needed before HTTP/1.1 can be made async.




            • Assignee:
              dfuchs Daniel Fuchs
              chegar Chris Hegarty
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: