HomeEIPsNewsletter
EIPsERC-7087
ERC-7087

MIME type for Web3 URL in Auto Mode

Add ability to indicate or determine the MIME type of the data returned by a Web3 URL in auto mode
DraftStandards Track: ERC
Created: 2023-05-28
Requires: EIP-6860
Qi Zhou (@qizhou), Nicolas Deschildre (@nand2)
DiscussionsOriginal linkEdit
1 min read
Anyone may contribute to propose contents.
Go propose
Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This standard extends the ERC-6860 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 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.
  • 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 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=<contentType>, where <contentType> is a MIME type defined in RFC 6838. If the <contentType> 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, <contentType> is set as the value of the Content-Type header of the response; or

  • mime.type=<fileType>, where <fileType> 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 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. If the returns query parameter is specified, the mime.xxx parameters will be ignored and the Content-Type will be defined by ERC-6860.

In RFC 2234 ABNF notation, the ERC-6860 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 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 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 and decode the data according to the RFC 2397 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 and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by