eclipse-vertx/vert.x · error · java.lang.UnsupportedOperationException

HTTP/1.x connections don't support GOAWAY

Error message

HTTP/1.x connections don't support GOAWAY

What it means

Http1Connection.goAway(long, int, Buffer) throws UnsupportedOperationException because GOAWAY is an HTTP/2-only connection-management frame; HTTP/1.x has no equivalent. Vert.x implements the shared HttpConnection API for both protocols, and HTTP/1.x versions of HTTP/2-specific operations hard-fail.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/http/impl/http1/Http1Connection.java:107

  @Override
  public Http1Connection closeHandler(Handler<Void> handler) {
    return (Http1Connection) super.closeHandler(handler);
  }

  @Override
  public HttpVersion protocolVersion() {
    return HttpVersion.HTTP_1_1;
  }

  @Override
  public Http1Connection exceptionHandler(Handler<Throwable> handler) {
    return (Http1Connection) super.exceptionHandler(handler);
  }

  @Override
  public HttpConnection goAway(long errorCode, int lastStreamId, Buffer debugData) {
    throw new UnsupportedOperationException("HTTP/1.x connections don't support GOAWAY");
  }

  @Override
  public HttpConnection goAwayHandler(@Nullable Handler<GoAway> handler) {
    throw new UnsupportedOperationException("HTTP/1.x connections don't support GOAWAY");
  }

  @Override
  public Http2Settings settings() {
    throw new UnsupportedOperationException("HTTP/1.x connections don't support SETTINGS");
  }

  @Override
  public Future<Void> updateSettings(HttpSettings settings) {
    throw new UnsupportedOperationException("HTTP/1.x connections don't support SETTINGS");
  }

  @Override

View on GitHub (pinned to fb308bd8c3)

Solutions

  1. Guard with a protocol check (e.g. connection instanceof Http2Connection / check negotiated version) before calling goAway
  2. For HTTP/1.x graceful shutdown, close the connection (connection.close()) or stop accepting new requests instead of sending GOAWAY
  3. Route the connection to the HTTP/2 path (enable h2/ALPN) if GOAWAY semantics are actually required

Example fix

// before
connection.goAway(0, 0, Buffer.buffer("bye")); // UnsupportedOperationException on HTTP/1.x
// after
if (connection instanceof Http2Connection) {
  ((Http2Connection) connection).goAway(0, 0, Buffer.buffer("bye"));
} else {
  connection.close(); // HTTP/1.x: no GOAWAY equivalent
}
Defensive patterns

Strategy: type-guard

Validate before calling

if (!(connection instanceof Http2Connection)) {
  // HTTP/1.x: cannot goAway; plan close() instead
}

Type guard

boolean supportsGoAway(HttpConnection c) {
  return c instanceof Http2Connection;
}

Try / catch

try {
  connection.goAway(0, 0, debugData);
} catch (UnsupportedOperationException e) {
  connection.close(); // HTTP/1.x fallback
}

Prevention

When it happens

Trigger: Calling connection.goAway(errorCode, lastStreamId, debugData) on an HttpConnection obtained from an HTTP/1.x request/response or HTTP/1.x client connection.

Common situations: Generic connection-drain/shutdown code written for HTTP/2 servers being reused on HTTP/1 endpoints; protocol negotiation falling back to HTTP/1.1 while code still calls GOAWAY to shed load.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/1d6f66494303defb. Report an issue: GitHub.