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?