[Feature]: Compression support via Content-Encoding in HttpBoot

[hpax]

Feature Overview

UEFI HTTP boot basically requires downloading a FAT image, which, being filesystems, tend to be rather inefficient. This is not a big deal on a disk, but they end up having to be transferred across the network as is, including padding bytes. The UEFI device model is inefficient for network transfers due to lack of interrupts, so image size is both a performance and reliability concern.

Compressing the image would alleviate this issue.

Solution Overview

The logical way to solve that problem would be to implement the Accept-Encoding: / Content-Encoding: part of HTTP. This doesn't even require any changes to the EFI spec; since it is negotiated as part of the HTTP protocol, it can be implemented directly in either HttpBootDxe or HttpDxe (I'm not sure which is better) and is simply a quality of implementation issue.

I'm noting that the Redfish part of EDK2 already does this, but only for Redfish, which is a very unfortunate layering violation since this ought to be available to all http clients, but especially HttpBoot.

I have done some testing, and I have found that by far the best tradeoff between performance and compression size is obtained using zstd, and zstd is already a standard HTTP content encoding. xz with the x86 filter does produce slightly smaller images, but at a substantially higher compression time cost, which will make it more difficult to act as a "drop-in" where most customers won't even notice that their UEFI clients and http servers now compress their data -- other than getting a faster boot; with xz it would probably be necessary for the customer to configure their web server with pre-compressed images. Furthermore, xz is not currently assigned any official IANA identifier.

gzip encoding, which the current Redfish code apparently uses, produces images that are about 40% larger than zstd, but still only about 45% of the uncompressed image size on the EDK2 tools build I used as a benchmark.

Alternatives Considered

It is too late for UEFI implementations to require "native" compression support. Either way, it is preferable for the compression to be negotiated with the server anyway, so using the http mechanism that already exists for that is the obvious.

It would be nice to have a Dxe that exports http as an EFI_SIMPLE_FILESYSTEM_PROTOCOL, so that anything accessing files in UEFI can do so over http, but that is a much bigger project and requires a bootstrap solution for older systems.

What packages are impacted?

NetworkPkg

Urgency

Medium

Are you going to implement the feature request?

Someone else needs to implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response