--- eip: 7087 title: MIME type for Web3 URL in Auto Mode description: Add ability to indicate or determine the MIME type of the data returned by a Web3 URL in auto mode author: Qi Zhou (@qizhou), Nicolas Deschildre (@nand2) discussions-to: https://ethereum-magicians.org/t/erc-7087-mime-type-for-web3-url-in-auto-mode/14471 status: Draft type: Standards Track category: ERC created: 2023-05-28 requires: 6860 --- ## Abstract This standard extends the [ERC-6860](./eip-6860.md) `web3://` standard: in smart contracts not designed for `web3://` (thus using auto mode), the MIME type of the returned data is either implicit (not advertised by the smart contract) or included within the returned data ([RFC 2397](https://www.rfc-editor.org/rfc/rfc2397) data URLs). This standard defines additional query parameters so that a MIME type can be returned when fetching a `web3://` URL in these scenarios. ## Motivation When returning data to the web browser, a `Content-Type` header indicating the MIME type of the data is strongly recommended, or the data may be incorrectly interpreted and displayed by the web browser. The `web3://` protocol has 2 modes: manual and auto. - The manual mode is used on smart contracts explicitly requesting this mode (via an interface), so they are expected to signal the MIME type of the returned data, with the mechanism described in [ERC-6860](./eip-6860.md). - On the other hand, the auto mode is used on both smart contracts specifically requesting the mode, and for all the others not signalling anything. While we can expect smart contracts explicitly requesting auto mode to signal the MIME type of the returned data, we cannot expect it for the others contracts. This standard aims at filling this gap: with the introduction of additional query parameters, it will allow the URL to specify the MIME type of the returned data. Additionally, when the returned data is a [RFC 2397](https://www.rfc-editor.org/rfc/rfc2397) data URL, it will allow the URL to flag the returned data as data URL, so that the protocol can return the decoded data, and accompany it with the MIME type advertised in the data URL. ## Specification The standard introduces three query parameters to determine the MIME type. - `mime.content=`, where `` is a MIME type defined in [RFC 6838](https://www.rfc-editor.org/rfc/rfc6838). If the `` does not follow the structure of a MIME type, the URL is not fetched and an error message is displayed to the user. After URL decoding, `` is set as the value of the `Content-Type` header of the response; or - `mime.type=`, where `` is a filename extension from which a MIME type is determined. If the filename extension is not recognized, the URL is not fetched and an error message is displayed to the user. The MIME type is then set as the value of the `Content-Type` header of the response; or - `mime.dataurl`, which indicates to decode the returned bytes as a [RFC 2397](https://www.rfc-editor.org/rfc/rfc2397) data URL. After decoding, the decoded body will be returned as the main output, and the MIME type specified in the data URL will be used. If the data cannot be parsed as data URL, an error will be returned. If multiple query parameters are present, the last query parameter will be applied. If none of the query parameter is specified, `Content-Type` is defined by [ERC-6860](./eip-6860.md). If the `returns` query parameter is specified, the `mime.xxx` parameters will be ignored and the `Content-Type` will be defined by [ERC-6860](./eip-6860.md). In [RFC 2234](https://www.rfc-editor.org/rfc/rfc2234) ABNF notation, the [ERC-6860](./eip-6860.md) syntax is : ``` attribute = attrName "=" attrValue attrName = "returns" / "returnTypes" attrValue = [ "(" [ retTypes ] ")" ] ``` This standard evolves it into: ``` attribute = retAttr / mimeCAttr / mimeTAttr / mimeDAttr retAttr = retAttrName "=" retAttrValue retAttrName = "returns" / "returnTypes" retAttrValue = [ "(" [ retTypes ] ")" ] mimeCAttr = "mime.content=" mimeCAttrVal mimeCAttrVal = # ABNF of MIME type as in RFC 6838 mimeTAttr = "mime.type=" 1*( ALPHA / DIGIT ) mimeDAttr = "mime.dataurl" ``` ### Examples #### Example 1 ``` web3://0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14/accessorizedImageOf/1289?mime.content=image/svg%2Bxml ``` where the contract is in auto mode. The protocol will call the contract `0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14` with the message defined in [ERC-6860](./eip-6860.md) and the returned `Content-Type` header will be set to `image/svg+xml`. #### Example 2 ``` web3://0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14/accessorizedImageOf/1289?mime.type=svg ``` where the contract is in auto mode. The protocol will call the contract `0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14` with the message defined in [ERC-6860](./eip-6860.md) and the returned `Content-Type` header will be set to `image/svg+xml`. #### Example 3 ``` web3://0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7/tokenURI/100?mime.dataurl ``` where the contract is in auto mode, and the returned data is `data:application/json,["xx"]`. The protocol will call the contract `0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7` with the message defined in [ERC-6860](./eip-6860.md) and decode the data according to the [RFC 2397](https://www.rfc-editor.org/rfc/rfc2397) data URL standard. The returned output will be ``["xx"]`` and the returned `Content-Type` header will be set to `application/json`. ## Rationale The standard uses three different query parameters rather than a single query parameter to avoid confusion - an implementer or a user can easily tell the expected returned MIME of a link. Further, in auto mode, the query parameters are not used to form the EVM message (e.g., calldata) and thus it is safe to introduce new query parameters. ## Security Considerations These new query parameters introduce Cross Site Scripting attack vectors : an attacker could exploit string or bytes returning methods he can influence by making them return unfiltered data injected by him, and then craft a URL to make the returned data interpreted as HTML, and then send the URL to victims. If the web3 hostname is well known, the victim may get a false sense of security. Malicious actions using javascript are broad and can include : - Extraction of data of web storage APIs (cookies, localStorage, sessionStorage, indexedDB), sent to the attacker - Triggering a signature request or transaction confirmation request (via a wallet javascript interface) Cross Site Scripting is a classical attack vector in HTTP websites, we expect developers to be wary of this. Nonetheless; the ability to specify the MIME type is unusual. `auto` mode websites should be discouraged and the attack vectors well documented. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).