CXPLAY on Nostr: 由于 urltransform 的特性, ...
由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.
除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 "Alt" 的资源瞎猜类型.
对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...
某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.
社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.
Published 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"
}