---
eip: 7618
title: Content encoding in ERC-5219 mode Web3 URL
description: In ERC-5219 resolve mode, add ability to decode a compressed resource before serving it to the client
author: Qi Zhou (@qizhou), Nicolas Deschildre (@nand2)
discussions-to: https://ethereum-magicians.org/t/erc-5219-resolve-mode/14088
status: Draft
type: Standards Track
category: ERC
created: 2024-02-08
requires: 5219, 6944
---

## Abstract

In the context of the [ERC-6860](./eip-6860.md) `web3://` standard, this ERC extends the [ERC-6944](./eip-6944.md) 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](./eip-6944.md) 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](./eip-6944.md) 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](../LICENSE.md).