Adds an ERC-4804 resolve mode for ERC-5219
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
the sources will be
1234 and query of
bar (space before
Could you please confirm this? @Pandapip1
That is correct.
Extra text so that this post is over the character minimum.
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
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?