HttpClient: improve handling of HTTP/2 GOAWAY frames with error code

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: P4
    • None
    • Affects Version/s: 17, 26
    • Component/s: core-libs

      Fail pending requests when a GOAWAY frame with a nonzero error code is received.

      Background:
      The GOAWAY frames in HTTP/2 serve dual purpose:
      - they can signal the intent to perform a graceful shutdown, indicated by error code = NO_ERROR
      - they are sent in response to a connection error, indicated by any other error code.

      According to RFC 9113 section 5.4.1:
      > An endpoint that encounters a connection error SHOULD first send a GOAWAY frame (Section 6.8) with the stream identifier of the last stream that it successfully received from its peer. The GOAWAY frame includes an error code (Section 7) that indicates why the connection is terminating. After sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection.

      JDK-8335181 changed the HttpClient behavior on receipt of a GOAWAY frame. Before the change, we would close the connection on receipt of a GOAWAY frame. After the change, we only close unprocessed streams and wait for further input from the server.

      If the server is acting on a connection error, it can be reasonably expected to close the connection immediately after sending the GOAWAY frame. This will fail all requests currently in progress on that connection with a generic exception message like "Connection closed by peer". The exception message should use the information from the GOAWAY frame instead.

            Assignee:
            Daniel Jelinski
            Reporter:
            Daniel Jelinski
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: