web3:// 返回的到底是什么图:ERC-7087 给自动模式补的 MIME 声明
把一段链上数据直接变成浏览器能看的页面,是 web3:// 协议的目标:不经过任何中间服务器,URL 本身就是对一个合约的调用。ERC-6860 定义了这个协议的两种模式——手动模式要求合约自己声明返回内容类型,自动模式则覆盖所有没有声明的合约。问题出在自动模式:浏览器强烈依赖 Content-Type 头判断一段字节该当图片、JSON 还是网页渲染,猜错了轻则乱码,重则酿成安全事故。ERC-7087 就是补这个洞的标准,创建于 2023 年 5 月 28 日,仓库记录状态为 Draft,依赖 ERC-6860 作为底座。
三个参数管一件事
标准引入三个查询参数,殊途同归都是给响应补 Content-Type。mime.content 直接写完整 MIME 类型,必须是符合 RFC 6838 结构的类型串,比如把链上画出来的 SVG 标注成 image/svg+xml;格式不对就不发起调用,直接报错。mime.type 写文件扩展名,协议把它映射成对应 MIME,扩展名不认识同样拒绝。mime.dataurl 最特别:它声明返回的字节本身是一个 RFC 2397 的 data URL,协议解码后把正文作为输出,MIME 取 data URL 里自带的那份;解不出来就报错。三者同时出现时,后写的生效;一个都不写则回到 ERC-6860 的默认判断;而 returns 参数一旦指定,这些 mime 参数全部被忽略。

对链上艺术的实际意义
对完全上链的作品,这条标准补上的是最后一步的语义。合约里的函数返回一串 SVG 文本,浏览器默认多半按纯文本处理;带 mime.type=svg 或 mime.content=image/svg+xml 的链接才可能被直接当矢量图渲染。返回 tokenURI 的合约也一样,data URL 打包的 JSON 元数据经 mime.dataurl 解码后,正文和类型各归其位。由于自动模式下这些查询参数不参与组装 EVM 调用数据,同一份合约数据挂不同 MIME 标注不会改变链上行为,这也让标准能安全地扩参数。
标准自己点破的风险
三个参数的语义差异可以再抠细一点。mime.content 是最直白的一种,适合你知道返回字节确切格式的场合,它直接成为响应头的 Content-Type;mime.type 面向文件名直觉,svg、json 这样的扩展名对普通作者更友好,代价是协议得维护一张扩展名映射表;mime.dataurl 处理的是一类历史现实——链上函数返回一个完整的 data: 前缀字符串,本体与元信息捆在一起。这种拆分和 HTTP 世界分道扬镳的理由在规范里写得很坦率:自动模式的合约作者没有义务也没有意识去声明内容类型,指望它们自己改代码不现实,于是把声明的责任交给拼 URL 的人——作者、策展页还是攻击者,谁拼这条链接,谁就决定浏览器怎么解释这段字节,攻防的分水岭就在这。
对索引器和钱包工具,这三个参数还意味着一层责任归属的清晰化。一条带 mime 标注的 URL 把怎么显示写进了链接自身,两个不同的策展页对同一段链上字节给出不同标注时,分歧被固定在了可比较的位置上,而不是藏在各自网关的默认行为里。判断一个 web3:// 浏览器实现的严谨度也能据此观察:对规范列出的无效值——不合规的类型串、认不出的扩展名、解不开的 data URL——正确做法是停下发错,若某工具选择静默猜测并照常渲染,它就在用最省事的方式把内容类型风险留给了你。
规范的安全考量写得坦率:能指定 MIME 类型本身就是新的攻击面。一个攻击者若能让某个返回字符串或字节的方法塞进自己注入的内容——例如他控制的合约字段或可影响的参数——再构造一条把返回内容标注成 HTML 的链接发给受害者,浏览器就会以该站点的身份执行脚本。可行的恶果包括窃取网页存储里的数据,或者诱导钱包弹出签名请求。规范因此明确建议不要鼓励使用自动模式站点,并把这类向量写进文档。读到这里可以总结一个通用姿势:对来路不明的 web3:// 链接,宁可把 URL 里每个 mime 参数都当作对方的选择来警惕,也不要因为域名眼熟就把返回的网页内容当真。本文为机制说明,不构成任何投资建议。
发表评论
还没有评论,来说两句吧。
评论区为展示样式,提交不会被处理。