由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.
除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 "Alt" 的资源瞎猜类型.
对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...
某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.
社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.
CXPLAY
npub1gd…ch58h
2024-09-14 13:45:36
in reply to nevent1q…ekss
Author Public Key
npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58hPublished at
2024-09-14 13:45:36Event JSON
{
"id": "c15f7d24ba10140e75fc317ee6ef8b29a77f758038862f3251d4de23b8a5c1f7",
"pubkey": "434f97993627f1e61f14eeaf60caa8cfdcec10a592caff8250c825252d548c15",
"created_at": 1726321536,
"kind": 1,
"tags": [
[
"e",
"0000d44774f86ff3c10a0dd6b25bb0ac3a8519bcf46ebf211387b9948f1e1491",
"wss://relay.nostr.band/",
"root"
],
[
"e",
"0000d44774f86ff3c10a0dd6b25bb0ac3a8519bcf46ebf211387b9948f1e1491",
"wss://relay.nostr.band/",
"reply"
],
[
"client",
"noStrudel",
"31990:266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5:1686066542546"
]
],
"content": "由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.\n除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 \"Alt\" 的资源瞎猜类型.\n\n对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...\n某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.\n\n社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.",
"sig": "327495682c2bd52dd72d17ae81ee210ced24605482ff54e48bd69207879cc6fff0cefb340b0b2a3b52e96ed8cc99f5a5d3c224b2ac4d09a52f580bb48fe3864a"
}