ERC-5219 Resolve Mode

Adds an ERC-4804 resolve mode for ERC-5219

PR is here Add EIP: ERC-5219 Resolve Mode by Pandapip1 · Pull Request #6944 · ethereum/EIPs · GitHub

And the gateways w3eth.io and w3link.io are now supporting the draft. A test contract can be browsed at testnet https://0x6587e67f1fbeaabdee8b70efb396e750e216283b.w3q-g.w3link.io/request/asdf/1234?abc=567&aaa=bar&xxx=yyy

The source code of the contract can be found at https://explorer.galileo.web3q.io/address/0x6587e67F1FBEAabDEe8b70EFb396E750e216283B/contracts

@Pandapip1 could you please take a look at the code and see if the gateway is working as intended (including customized response headers)

One more question is regarding URL encoding/decoding, where we should expect the inputs of the following function

function request(string[] memory resource, KeyValue[] memory params) external view returns (uint16 statusCode, string memory body, KeyValue[] headers);

are the UTF-8 encoded string after URL decoding the Web3 URL?

For example, for the following Web3 URL

web3://0x6587e67f1fbeaabdee8b70efb396e750e216283b:3334/asdf%CE%B1/1234?abc=567&aaa=%20bar&xxx=yyy

the sources will be asdfα / 1234 and query of aaa is bar (space before bar).

Could you please confirm this? @Pandapip1

1 Like

That is correct.
Extra text so that this post is over the character minimum.

1 Like

Hi!

In the ERC-5219 contract interface, the returned body is of type string, so question:
Is it intended that only text should be returned, or any binary data could be returned, and I guess the interface needs to be updated with bytes instead of string?

Use case: I could easily see non text data be returned, e.g. some stored gzipped content, some crafted binary data, …

ERC-5219 being final, what would be the best way forward?

  • Add an alteration on ERC-6944 indicating a slight change? It would be a bit messy.
  • Like ERC-6860 was created to evolve a final ERC-4804, create a new ERC to evolve 5219, with binary return support, and also input HTTP header support?