In the context of the ERC-6860 web3:// standard, this ERC extends the ERC-6944 resolve mode: This standard specifies that if a Content-Encoding header is returned by the request() call, then the returned data is decoded if necessary according to the specified algorithm before being returned to the client.
As storage in blockchains is expensive, it is optimal to try to store and serve compressed assets. Standard HTTP uses the Accept-Encoding/Content-Encoding mechanism, in which the client specifies their supported compression algorithms, and the server returns the data compressed in one of them. It is not optimal to replicate this mechanism in the web3:// protocol, due to blockchain storage and computation constraints. Moreover, it is not possible to blindly serve content with a fixed Content-Encoding header, because the HTTP client may not implement the compression algorithm.
By specifying a list of supported compression algorithms, optionally doing the decompression at the protocol side and serving the data to the client, we can safely store compressed data and serve it.
In the ERC-6944 resolve mode, this standard indicates that if a Content-Encoding HTTP header (in the returned headers KeyValue array of the request() method) is provided, and if it is not part of the supported algorithms provided by the client in the Accept-Encoding header, or the client did not provide an Accept-Encoding header, then the protocol MUST decode the content before forwarding it to the web3:// client.
The protocol MUST support the following content encodings: gzip, br (brotli). If the protocol is to decode the content, and if the advertized Content-encoding is not part of this list, an error indicating an unsupported content encoding MUST be sent to the client. Once decoded, the decompressed data is sent to the client. The Content-Encoding header MUST NOT be forwarded to the client when the protocol decodes the content.
We add this feature to the ERC-6944 resolve mode because it can be added without changes the interface.
To stay as close as possible to standard HTTP, we don't introduce a new HTTP header but reuse the known Content-Encoding header.
No security considerations were found.
Copyright and related rights waived via CC0.