njump 本身是对 TwitterBot 做了单独的 case 适配的, 但可惜用得是 UserAgent 关键词匹配, TelegramBot 的 UA 又偏偏带个 "like TwitterBot", 于是乎 TelegramBot 的请求进来不管怎么样都会被匹配到 Twitter 的元数据条件. 除非给 TwitterBot 的 UA 进行全字匹配, 不知道可不可行.
这次的预览改造还是比较成功的, 迟早也要提交给上游, 还是要做好适配.
顺便吐槽一下 Twitter 的网页预览, 非要做得这么独特, 不显示描述了, 之前莫名其妙的文字转换图片就是 njump 设计之初考虑到 Twitter 才这么做的. 现在看来最好的办法是给 TwitterBot 单独组装 meta 标签, 太弱智了, 反正我也不用 Twitter 发帖, 再说了, 又不是不能用. :bili_fantastic:
https://media.naeu.net/71e5cc47223428e2df8ece9d073d8ef5708a95733ad9f0a76e5ce6e592209958.webp
njump 本身是对 TwitterBot 做了单独的 case 适配的, 但可惜用得是 UserAgent 关键词匹配, TelegramBot 的 UA 又偏偏带个 "like TwitterBot", 于是乎 TelegramBot 的请求进来不管怎么样都会被匹配到 Twitter 的元数据条件. 除非给 TwitterBot 的 UA 进行全字匹配, 不知道可不可行.
这次的预览改造还是比较成功的, 迟早也要提交给上游, 还是要做好适配.
给 TwitterBot 单独生成元数据标签之后发现 Cloudflare 的「按设备类型缓存」并非是按照设想中的会分隔 Bot 的缓存.
https://developers.cloudflare.com/automatic-platform-optimization/reference/cache-device-type/
CF 公开的正则里面只有把 GoogleBot 划分在了移动设备里, 而其他的 Bot 被排除, 统统读到桌面端设备的缓存, 如果有桌面设备或者其他 Bot 先行一步让 CF 缓存了页面, 后续 TwitterBot 进来也就没办法读到单独为它准备的元数据标签.
怎么办呢? 不放弃缓存的情况下, 看起来只能给 TwitterBot 开绿灯让它绕过缓存直接回源了.
还有种办法是用服务端规则把 Twitter 的流量重定向到一个额外带有特殊查询字串符的 URL, 这样服务端由于查询字串符就会重新回源, 给 TwitterBot 生成元数据标签, 然后还能继续缓存起来.