Trimming Http in Blazor wasm

[CoffeeFlux]

System.Net.Http is one of the largest libraries in the Blazor sample, taking up 53KB when compressed with Brotli. Most of this space is held in the headers, most of which are not likely to be used. We should investigate some sort of feature flag here to try and get rid of this even if the linker cannot guarantee it will be unused.

The size grew also when http2 and http3 support was added for SocketHttpHandler which is not used and excluded for Browser and still the various caches and static data are populated.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:	System.Net.Http is one of the largest libraries in the Blazor sample, taking up 53KB when compressed with Brotli. Most of this space is held in the headers, most of which are not likely to be used. We should investigate some sort of feature flag here to try and get rid of this even if the linker cannot guarantee it will be unused.
Issue author:	CoffeeFlux
Assignees:	-
Milestone:	[object Object]

[stephentoub]

The vast majority of that code is around header validation, e.g. when you set HttpRequestHeaders.From on a message, it validating that it's a well-formed email address. I think the flag here will basically need to be "I don't care about header validation at the HttpClient layer", at which point I'd expect a significant portion of the header logic could be trimmable away.

Alternatively, we could simply say that for the Blazor wasm build we don't layer on much special validation, and simply have a different implementation that effectively ifdefs away all of that code. More specifically, much of it ends up being kept because of the parsers defined in the known headers here:
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Http/src/System/Net/Http/Headers/KnownHeaders.cs
We would tweak that for the wasm build to just always use a generic parser, or something like that.

cc: @geoffkizer

[eerhardt]

@geoffkizer @wfurt @scalablecory @dotnet/ncl - anyone have any thoughts on the above? Would either of these approaches be acceptable in browser-wasm (and potentially mobile) builds?

[geoffkizer]

We can't rip out the header parsers/validators in general without removing strongly typed header properties as well, which I assume we don't want to do....

Is there a way to see details on what methods account for what space, etc?

[eerhardt]

Is there a way to see details on what methods account for what space, etc?

You can use the following steps to trim a default Blazor WASM app:

1. Get the latest 6.0 SDK and put it on your $PATH
2. Create a HelloWorld directory and cd into it
3. dotnet new blazorwasm
4. dotnet publish -c Release
5. Inspect the .dlls in HelloWorld\bin\Release\net6.0\publish\wwwroot\_framework. You'll see the System.Net.Http.dll is the 3rd largest after CoreLib and System.Text.Json. Currently around 136 KB. Typically I use ILSpy or similar to inspect what is left in the assembly.

When I do this, here is what is left:

Analyze these classes and decide whether each is completely necessary in a browser-wasm app.

[geoffkizer]

The HPACK and QPACK stuff is HTTP2/3 specific and could be removed, though I expect there's some trickiness with the KnownHeaders stuff that makes this a bit painful.

I don't know what TaskToApm is used for; we could investigate this but I doubt it's much code.

As for the rest, I don't see much that can be removed, unfortunately.

[stephentoub]

We can't rip out the header parsers/validators in general without removing strongly typed header properties as well, which I assume we don't want to do...

I was thinking we could consider weakening the validation. For example, there's a ton of code purely to validate that From headers are properly formatted as email addresses. Do we need all of that for wasm?