Content encoding in ERC-5219 mode Web3 URL
Video
Original
Abstract
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.
Motivation
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.
Specification
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.
Rationale
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.
Security Considerations
No security considerations were found.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all