On Tue, Apr 14, 2026 at 02:34:21PM +0000, Mike Bishop wrote: > Those are excellent reasons for mandating some form of compression, and > perhaps for having a MTI to ensure that there's some overlap. > > Characterizing content negotiation as "opportunistic" compression misstates > what HTTP communicates with Content-Encoding. C-E describes the resource > being sent. The gzipped file can be created in advance and served from disk > by the server. You can require that your protocol's use of HTTP supports at > least gzip, if you're concerned about accidentally sending it uncompressed. > That's distinct from server features that can dynamically compress (or > decompress, or recompress) when the compression schemes supported by the > client differ from what the server has on disk.
I understand these things can done, and I too like the concept of pre-calculating compressed forms to reduce the cost of on-the-fly compression. (I'll note that creating Gzip files in advance is exactly what the existing NRTMv4 already supports.) However, what you suggest to me seems a fair bit of fiddling with lower-level aspects of the deployment stack, perhaps more than NRTM application operators might have control over... > If there's a separate HTTP ecosystem issue in support of C-E, I think > that more details about that would be of interest to the HTTP working > group. I don't see those details in the link you pointed to, simply the > observation that only 61% of the servers properly supported compression > in that test. Some details are in the email body: multiple brand-name vendors somehow ended up with products that don't trivially support Gzip content-encoding compression in the end-to-end movement of data. This came as a surprise to me, but it is what it is. Middleboxes meddling with things... The customers of content distribution services (for example, Regional Internet Registries) apparently don't always get to pick their supplier, or the staff inside these RIRs organisations don't always get to control the HTTP server configuration, or phrased differently: NRTM operators don't always get to make it so that Gzip C-E is _always_ used. I'm concerned that this specification mandating that Gzip content-encoding be used for HTTP transfers won't make it so in reality. This is why a decision was made to just make compression an integral part of this protocol in the way it was done, this was subsequently implemented, and seems to work for those who run NRTM services. The operational experience with RRDP has shown me that it takes far more effort energy to make HTTP compression work reliably for large resources than it is to make pre-compression an integral part of protocols for large data syncing. Can you clear your DISCUSS on this topic? Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
