GitHub
Release Xray-core v24.11.21 · XTLS/Xray-core
XHTTP client: Add gRPC header to "stream-up" mode by default #4042
这个版本为 stream-up 模式的上行 POST 请求默认加上了 gRPC 标头，经测试 CF H2 支持它，详见 #4042
所以，顺便把客户端 auto 的行为改为了 TLS H2 或 REALITY 时默认 stream-up，请...
这个版本为 stream-up 模式的上行 POST 请求默认加上了 gRPC 标头，经测试 CF H2 支持它，详见 #4042
所以，顺便把客户端 auto 的行为改为了 TLS H2 或 REALITY 时默认 stream-up，请...
Xray-core v24.11.21: https://github.com/XTLS/Xray-core/releases/tag/v24.11.21
这次有没有又开启了一个崭新的时代不重要，支持一下 Project X NFT 非常重要：Announcement of NFTs by Project X #3633
😁34👍12⚡4
Telegram
聖園ミカ😈Ciallo～(∠・ω< )⌒ in Project X
我单写h1也不通，只能单写h2
https://t.me/projectXray/4080216
TLS ALPN 写了且只写一个的话，auto 会选 packet-up，否则 stream-up
好在新版还把 packet-up 上行遗留问题修好了，但更建议用 stream-up
TLS ALPN 写了且只写一个的话，auto 会选 packet-up，否则 stream-up
好在新版还把 packet-up 上行遗留问题修好了，但更建议用 stream-up
👍18👀3⚡1
GitHub
Release Xray-core v24.11.21 · XTLS/Xray-core
XHTTP client: Add gRPC header to "stream-up" mode by default #4042
这个版本为 stream-up 模式的上行 POST 请求默认加上了 gRPC 标头，经测试 CF H2 支持它，详见 #4042
所以，顺便把客户端 auto 的行为改为了 TLS H2 或 REALITY 时默认 stream-up，请...
这个版本为 stream-up 模式的上行 POST 请求默认加上了 gRPC 标头，经测试 CF H2 支持它，详见 #4042
所以，顺便把客户端 auto 的行为改为了 TLS H2 或 REALITY 时默认 stream-up，请...
Xray-core v24.11.21: https://github.com/XTLS/Xray-core/releases/tag/v24.11.21
蓦然回首，XHTTP 已经成为了很多场景下，尤其是穿透 CDN 时的最佳选择，Make Xray Great Again！
蓦然回首，XHTTP 已经成为了很多场景下，尤其是穿透 CDN 时的最佳选择，Make Xray Great Again！
👍38🔥3
Project X Channel pinned «Xray-core v24.11.21: https://github.com/XTLS/Xray-core/releases/tag/v24.11.21 这次有没有又开启了一个崭新的时代不重要，支持一下 Project X NFT 非常重要：Announcement of NFTs by Project X #3633»
Project X Channel pinned «Xray-core v24.11.21: https://github.com/XTLS/Xray-core/releases/tag/v24.11.21 蓦然回首，XHTTP 已经成为了很多场景下，尤其是穿透 CDN 时的最佳选择，Make Xray Great Again！»
Telegram
HIYA in Project X
XHTTP+REALITY 速率还不如 TCP+REALITY快
https://t.me/projectXray/4080394
看来风扇出的题难度有待提升，群里竟然无一人指出，这就是最简单的多路复用+多线程测速问题，XHTTP 的 XMUX 设 maxConcurrency=1，多线程测速的速度自然就上去了
👍14😁7❤1
Telegram
David in Project X
用grpc就没必要用xhttp了吧
https://t.me/projectXray/4083701
推荐把 gRPC 都换成 XHTTP，光是有 XMUX 就值得了，更多的查看 https://github.com/XTLS/Xray-core/pull/4042
事实上，如果几年前就发现了加个 gRPC 标头就能过 CDN，就不会有 gRPC 这个传输层了
推荐把 gRPC 都换成 XHTTP，光是有 XMUX 就值得了，更多的查看 https://github.com/XTLS/Xray-core/pull/4042
事实上，如果几年前就发现了加个 gRPC 标头就能过 CDN，就不会有 gRPC 这个传输层了
👍25🔥2
Forwarded from GitHub
💬 New comment on Xray-core#3994 XHTTP: Add "stream-up" mode for client & server
by @RPRX
~~重新决定一下~~，明天写个 stream-one 模式，即把 HTTP 传输层并入 XHTTP，~~正式补上最后一块拼图~~，相当于 HTTP 传输层也有了 header padding、XMUX 等功能而不用维护两份代码和~~名称滥用~~，但不应默认兼容原 HTTP 传输层所以应默认检查 x_padding
Reply to this message to post a comment on GitHub.
by @RPRX
~~重新决定一下~~，明天写个 stream-one 模式，即把 HTTP 传输层并入 XHTTP，~~正式补上最后一块拼图~~，相当于 HTTP 传输层也有了 header padding、XMUX 等功能而不用维护两份代码和~~名称滥用~~，但不应默认兼容原 HTTP 传输层所以应默认检查 x_padding
Reply to this message to post a comment on GitHub.
👍20
Telegram
风扇滑翔翼 in Project X
别继续break了。。(padding是可以关的 让它关掉之后可以兼容也行 不过它还检查这个？如果本来没有最好别无聊加上)
HTTP这个名字并不是滥用 它就是正常的HTTP双向流 没有v2专有的东西
HTTP这个名字并不是滥用 它就是正常的HTTP双向流 没有v2专有的东西
https://t.me/projectXtls/513?comment=4086171
HTTP 传输层一直以来连 header padding 都没有，固定包长早就能被精准识别了，如果现在给它加就陷入了要维护两份代码的问题
HTTP 传输层一直以来连 header padding 都没有，固定包长早就能被精准识别了，如果现在给它加就陷入了要维护两份代码的问题
👍15❤1
Telegram
风扇滑翔翼 in Project X
建议删掉这个略迷惑还污染nginx日志(一堆难绷0 估计很多人都见过)的path padding 统一用header 用XHTTP会自行启用 新mode和老HTTP互相兼容 用带X的就有padding或者一堆别的附加功能
https://t.me/projectXtls/514?comment=4086201
原设计都是 header，但 mmmray 发现 browser dialer 会出问题，所以改成了 path，翻翻以前的讨论
协议的安全性更新不应兼容过去，原因是会被猪队友害了，Vision 最初兼容无 flow 就有不少人被封端口，改成不兼容了才清净
所以你们这些给他点赞的人是觉得比我们更懂该怎么设计协议吗，要不你们来
原设计都是 header，但 mmmray 发现 browser dialer 会出问题，所以改成了 path，翻翻以前的讨论
协议的安全性更新不应兼容过去，原因是会被猪队友害了，Vision 最初兼容无 flow 就有不少人被封端口，改成不兼容了才清净
😁26
Telegram
风扇滑翔翼 in Project X
场景不一样啊又没一大把人用HTTP 而且flow不兼容空又没说把空flow删了 如果能兼容并进去就并进去了 不能兼容删了这
https://t.me/projectXtls/515?comment=4086209
就是因为没多少人还在用 HTTP 传输层才没那么 break，服务端要加检查 x_padding 也是防止猪队友客户端，当然如果你服务端设个 -1 也就不会检查 x_padding 也就完全兼容原 HTTP 了，虽然我不建议大家这样做也没必要这样做
此外 HTTP 传输层名称的问题还在于我们还有个代理协议也叫 HTTP，容易搞混，而且 fly v5 都扔了，别有 sb 提 VLESS，那不是一回事
此外 HTTP 传输层名称的问题还在于我们还有个代理协议也叫 HTTP，容易搞混，
👍9👀3
Project X Channel
https://t.me/projectXtls/515?comment=4086209 就是因为没多少人还在用 HTTP 传输层才没那么 break，服务端要加检查 x_padding 也是防止猪队友客户端，当然如果你服务端设个 -1 也就不会检查 x_padding 也就完全兼容原 HTTP 了，虽然我不建议大家这样做也没必要这样做 此外 HTTP 传输层名称的问题还在于我们还有个代理协议也叫 HTTP，容易搞混，而且 fly v5 都扔了，别有 sb 提 VLESS，那不是一回事
Telegram
风扇滑翔翼 in Project X
fly没扔 没人写文档而已
https://t.me/projectXtls/516?comment=4086229
代码没扔主要是因为还要兼容 v4，v5 没它文档态度已经很明确了，可能是因为他们的 h2 还有些 bug 没修，现在发现能过 cf 可能又会捡回来，Xray 这边是去年我搞 REALITY 时把 h2 的 bug 修了才有人捡起来用，anyway 我自己修好的东西我删掉都不心疼
代码没扔主要是因为还要兼容 v4，v5 没它文档态度已经很明确了，
🔥14👍2
Telegram
风扇滑翔翼 in Project X
其实我想保它的原因是它是ray的所有transport里除了直进直出的tcp外最好实现的一个 绝大多数语言只需要标准库就能写出来
😁23⚡6👀3
Telegram
jiang zhexin in Project X
幽默padding=复杂
这个也挺抽象的，话说回来要求 header padding 又不复杂，且不实现 XMUX 也能兼容 XHTTP stream-one，更没理由保 HTTP 传输层了
👍12
GitHub
XHTTP: Add "stream-one" mode for client & server by RPRX · Pull Request #4071 · XTLS/Xray-core
新文章已发布：XHTTP: Beyond REALITY
注意 stream-one 如果填 /yourpath，实际请求的是 /yourpath/，若末尾没有 / 会自动补上
#3994 (comment) 让我们补上 XHTTP 近期最后一大块拼图：
现有的 HTTP 传输层使用“一条子连接”承载一条被代理请求，即没有任何上下行逻辑分离。但它一直以来存在一个没有 header pa...
注意 stream-one 如果填 /yourpath，实际请求的是 /yourpath/，若末尾没有 / 会自动补上
#3994 (comment) 让我们补上 XHTTP 近期最后一大块拼图：
现有的 HTTP 传输层使用“一条子连接”承载一条被代理请求，即没有任何上下行逻辑分离。但它一直以来存在一个没有 header pa...
XHTTP: Add "stream-one" mode for client & server
新模式的加入也使得 XHTTP 更加完备，预计月底 release，正好接棒一个月：借我一个月，还你们一个完全体 XHTTP
REALITY 的 NFT 也即将发行，别错过收藏 Project X NFT 送 REALITY NFT 的最后机会：Announcement of NFTs by Project X
（初始售价 0.033 ETH 的 Project X NFT 现已涨至 0.18 ETH，且还会送 REALITY NFT，只能说越早上车越香，现在才刚开始）
新模式的加入也使得 XHTTP 更加完备，预计月底 release，正好接棒一个月：借我一个月，还你们一个完全体 XHTTP
REALITY 的 NFT 也即将发行，别错过收藏 Project X NFT 送 REALITY NFT 的最后机会：Announcement of NFTs by Project X
（初始售价 0.033 ETH 的 Project X NFT 现已涨至 0.18 ETH，且还会送 REALITY NFT，只能说越早上车越香，现在才刚开始）
👍33⚡4🔥3😁2