/cc @bradfitz

Is it viable to instead make just the HTTP/1 client available in an external package, and use that instead of net/http? Similarly to how HTTP/2 exists in golang.org/x/net/http2 in addition to net/http.

The challenge of adding a build constraint for this is that it adds a new configuration that’ll need to be tested, and it may scale poorly when there’s also HTTP/3.

The challenge of adding a build constraint for this is that it adds a new configuration that’ll need to be tested,

We already do similar with osusergo and netgo and have a testing story there. (test that they compile in a separate cmd/dist test). I don't think we'd need any builder coverage other than making sure it compiles.

We started some simple discourse on Twitter. I suggested

+build !no_http2
OR
+build !disable_http2
For the h2_bundle.go file

and @bradfitz replied with

Double negatives always suck but probably unavoidable. At least we can avoid "not no". Like "not omit". Maybe omithttp2. It's not disabled. It doesn't exist. We don't generally use underscores in build tags.

and I agreed with

Yeah:
+build !omithttp2
works. I like the “omit” prefix

So a current pitch is to use +build !omithttp2 if using building tags

The existing precedent seems to be to prefix the build tag with the package name (netgo for the net package, osusergo for the os/user package). If we kept that up it'd be nethttpomithttp2 which is kinda a mouthful but ... specific. I'm okay with it.

We'd probably want to make the clientServerTest helper just t.Skip when http2 isn't compiled in. Hopefuly it's not much more than that.

In any case, I'm fine with this, especially if it's as small of a patch as I'm imagining. I haven't tried.

@crawshaw
Knowing workaround to memory limit of iOS App Extension :

using go1.9.x

Changing to NeedsFix per #35082 (comment). Should go back to NeedsDecision if there are complications.

On a related note, this will help reduce wasm binary sizes too.

If you import golang.org/x/net/http2 to get the "latest" http2 then you still end up with two HTTP2 stacks in your binaries, one just dead code. I wonder if we can do anything to fix that more general problem of being able to sub in a new http2 and actually drop the old one.

If we did that, then @crawshaw's use case could import an "emptyhttp2" instead.

@bradfitz says the "right" fix is a ways off if it's anywhere. The build tag is fine to solve this specific problem in the short term.

Change https://golang.org/cl/205017 mentions this issue: cmd/bundle: add -tags flag

Change https://golang.org/cl/205139 mentions this issue: net/http: support disabling built-in HTTP/2 with a new build tag