JDK-8161157 : HTTP/2, there is no way to process PUT request with no body received. Either memory leak or client hang up.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-07-11
  • Updated: 2016-12-09
  • Resolved: 2016-12-09
Related Reports
Duplicate :  
Description
Issue 1 - Inconsistency between Java doc and actual HttpClient behavior.
HttpResponse java-doc says:
" The body or bodyAsync which retrieve any response body must be called to ensure that the TCP connection can be re-used subsequently, and any response trailers accessed, if they exist, unless it is known that no response body was received."
Particularly for HTTP/2 implementation, if "body" or "bodyAsync" invocation is omitted (even if it is knows that no response) - it causes memory  leak, because of Stream will be never deleted.

Issue 2: attempt to invoke "body" causes client blocking.
In case of HTTP1.1 protocol "HttpResponse.body(HttpResponse.asByteArray())"  provides proper result (empty array).
In case of HTTP/2 protocol client blocks on "Stream.receiveData" invocation waiting DataFrame.

Processing PUT requests with no returned data HTTP/2 server may not send DataFrame at all. In such case HTTP/2 server sends returned HeadersFrame with END_STREAM flag. HttpClient doesn't have code to process such behavior.

Comments
Fixed in sandbox.
09-12-2016

Sorry, I thought that link was to the changeset I pushed today. There were additional problems on the test server that needed to be fixed. Also, the client needed to handle the case where no DATA frames at all are received and the HEADERS or CONTINUATION frame contains the END_STREAM flag.
23-08-2016

Issues 2 has been fixed in the sandbox by http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/30eb69420ae2 , right ?
23-08-2016

Issue 1 is resolved with API change. Bodies always downloaded now. Issue 2 resolved in sandbox
23-08-2016