With HTTP2 there is no more chunked encoding, instead it's built into the stream system. Now in many use cases the server may proxy responses back from other systems, or generate them on the fly, in which cases there is no content-length. It is possible that the proxying / processing breaks, and then it's not clear how to communicate the breakage to the client. If you just return the handler, the HTTP2 library will wrap it up like nothing happened and user will get truncated data.

With HTTP1, the common trick is to just hijack and close the connection. This works well.

	if err == io.ErrUnexpectedEOF {
		// the upstream closed on us ungracefully.
		// if no content-length, need to notify downstream that content is incomplete.
		// In HTTP1.1 means closing connection, which requires hijacking.
		if rw.Header().Get("Content-Length") == "" {
			if hj, ok := rw.(http.Hijacker); ok {
				conn, _, _ := hj.Hijack()
				conn.Close()
			}
		}
	}

A similar question for HTTP2 was asked here #14797
To which the answer from @bradfitz was to just panic. But this seems messy since the app may still have other processing to do related to this request, and at minimum things like access logging. It just feels unnatural to panic in this case, and difficult to understand what truly happens over Go revisions without testing (does stream get closed? Or just will time out?).

Would it be possible to expose the equivalent of a Hijack for HTTP2 streams, where one could explicitly abort the stream if needed?
Thanks!

What version of Go are you using (go version)?

1.9.2

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

osx

What did you do?

What did you expect to see?

What did you see instead?