ERC-7618: ERC-5219 模式 Web3 URL 中的内容编码
在 ERC-5219 解析模式中，添加在将压缩资源提供给客户端之前对其进行解码的能力
| Authors | Qi Zhou (@qizhou), Nicolas Deschildre (@nand2) |
|---|---|
| Created | 2024-02-08 |
| Discussion Link | https://ethereum-magicians.org/t/erc-5219-resolve-mode/14088 |
| Requires | EIP-5219, EIP-6944 |
摘要
在 ERC-6860 web3:// 标准的上下文中，此 ERC 扩展了 ERC-6944 解析模式：此标准指定，如果 request() 调用返回了 Content-Encoding 标头，则在将返回的数据返回给客户端之前，必须根据指定的算法对返回的数据进行解码（如果需要）。
动机
由于区块链中的存储成本很高，因此尝试存储和提供压缩的资产是最佳的。标准 HTTP 使用 Accept-Encoding/Content-Encoding 机制，客户端在其中指定其支持的压缩算法，服务器返回使用其中一种算法压缩的数据。由于区块链存储和计算的限制，在 web3:// 协议中复制此机制并不理想。此外，盲目地提供带有固定 Content-Encoding 标头的内容是不可能的，因为 HTTP 客户端可能没有实现该压缩算法。
通过指定支持的压缩算法列表，选择性地在协议端进行解压缩并将数据提供给客户端，我们可以安全地存储压缩数据并提供它。
规范
在 ERC-6944 解析模式中，此标准指示，如果在 request() 方法返回的 headers KeyValue 数组中提供了 Content-Encoding HTTP 标头，并且它不是客户端在 Accept-Encoding 标头中提供的支持算法的一部分，或者客户端没有提供 Accept-Encoding 标头，则协议必须在将内容转发到 web3:// 客户端之前对其进行解码。
协议必须支持以下内容编码：gzip、br (brotli)。如果协议要解码内容，并且如果声明的 Content-encoding 不在此列表中，则必须向客户端发送指示不支持的内容编码的错误。解码后，解压缩的数据将发送到客户端。当协议解码内容时，Content-Encoding 标头不得转发给客户端。
原理
我们将此功能添加到 ERC-6944 解析模式，因为可以在不更改接口的情况下添加它。为了尽可能接近标准 HTTP，我们不引入新的 HTTP 标头，而是重用已知的 Content-Encoding 标头。
安全考虑
未发现任何安全考虑。
版权
在 CC0 下放弃版权及相关权利。
Citation
Please cite this document as:
Qi Zhou (@qizhou), Nicolas Deschildre (@nand2), "ERC-7618: ERC-5219 模式 Web3 URL 中的内容编码 [DRAFT]," Ethereum Improvement Proposals, no. 7618, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7618.