Prohibit the use of content codings that don't provide byte-for-byte equivalence

[LPardue]

Section 5 of Unencoded-Digest explains the considerations related to content codings that don't produce a byte-for-byte equivalent output after decode; see https://httpwg.org/http-extensions/draft-ietf-httpbis-unencoded-digest.html#section-5

Since the success of this protocol hinges on correct validation, a poor choice of content coding could lead to unanticipated failures.

To mitigate that, it probably makes the most sense for this document to normatively prohibit the use of any such content codings. I.E. MUST NOT use (and possibily even... or else the client MUST fail validation).

[mikewest]

Sure, it's reasonable to add that as a consideration here (though I suspect these encodings are not widely used, and unlikely to be a problem in practice...). Is the best we can do "REALLY SHOULD NOT use content encodings that don't provide byte-for-byte equivalence"? Or is there a list of encodings that we could actively fail upon encountering?

[LPardue]

AFAIK there is only one registered encoding that can act this way. However, content coding is an extension and there might be future issues that come down the line.

I think the answer might depend on the failure model and how easy it is to detect issues. If some new content-encoding is invented and unwittingly enabled for some subset of traffic leading to intermittent or hard to detect issues that's a bit different to turning the new thing on and seeing 100% of a canary trial failing and backing it out immediately.

When this issue was discussed on the Unencoded-Digest draft (httpwg/http-extensions#3339), the only example of registered content coding [1] offered was exi, defined in https://www.w3.org/TR/exi/. A quick AI-powered check indicates no browsers implement it (and given its age, maybe they never will).

Perhaps this ecosystem allows us to be more proscriptive on client requirements? For example, if it expects to load a resource using signature integrity don't offer problematic encoding in the first place.

Regarding reporting, I'm not familiar enough to know if the details of the Content-Encoding would be availble in the "network error".

[1] - https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding

[LPardue]

If we were to use a crystal ball, one might imagine that the proposed benefits of EXI (efficient XML) might be sought out for the Agent-based future wrt JavaScript-oriented stuff. I'm recallign some of the work in TC39 on Binary AST several years back (https://blog.cloudflare.com/binary-ast). Or maybe BSON etc. However, that model pushes the compression into the content itself, rather than as an HTTP layer content coding.

I'm not sure the probability we'd ever see a non byte-for-byte content coding that would get uptake in this space.