REALITY: Unblock SplitHTTP transport

[mmmray]

Suggested in #3788

It seems to just work, so I removed the check. After all, with the mux settings and strange upload, it could be useful (although the mux can also be ported to h2 and grpc)

[RPRX]

那我想这个版本就把 H2 传输层删了，命名为 HTTP 实在是

[mmmray]

No, this is actually not enough. The transport needs dedicated code for it. Otherwise the security setting will be ignored. Ah well, I thought I'd just shoot out a one-liner to unblock some testing. I'll resume the work later.

[mmmray]

well, here's another thing that bugs me. N transports need to support M security settings, resulting in N * M lines of code. and NextProto still doesn't work

[Fangliding]

Just use reality.UClient to replace tls.Client should be enough I guess

[Fangliding]

and NextProto still doesn't work

RPRX thinks APLN should not able to be modified by user config
This is related to copyConfig() func, I think user config checking can be moved front, and allow to change alpn in code

[KobeArthurScofield]

Or just don't let it use HTTP/1.1 with reality, like why reality doen not work with WebSocket and HTTPUpgrade

[RPRX]

@mmmray 你研究下 chrome 支持的 streaming request，支持 browser dialer，把 SplitHTTP 重命名为 XHTTP，加个参数 mode，现在的两种分别为 splitupload 和 normalupload，结合 REALITY 时默认后者否则默认前者，我写一下可以在 path 中配置这些参数

[RPRX]

Streaming request 模式就叫 normal，不用加 upload 后缀

[mmmray]

?upload=normal / ?upload=chunked

[RPRX]

?upload=normal / ?upload=chunked

或许这样也行

[RPRX]

#3823 (comment)

[RPRX]

@mmmray 应该有空先把这个 PR 完成吧，剩下的我来

[mmmray]

I haven't forgotten about this and the linked plan, just catching up with notifications.

[mmmray]

so this is now complete reality for splithttp, trying to figure out how to merge it with http transport. if i understood you right, you want reality in xhttp, but not in splithttp (good incentive to upgrade)

aesthetically, I would also prefer to keep the transports separate and not do this querystring hack (after all, if functionality is important, clients will add it anyway, see fragment), but I can kind of see that it would be good to have xray pick the "right" transport depending on whether REALITY is selected or not.

[RPRX]

我一直认为 @mmmray 是将 SplitHTTP 重命名为 XHTTP 的最佳人选，so，the plan is：

1. 将 HTTP 传输层的 H2、H3 并入 SplitHTTP，同样默认有 header padding 和 XMUX，同时 SplitHTTP 也支持了 REALITY
2. 支持旧版配置的转译，提醒迁移，v25 删掉转译代码
3. 若写 XHTTP，安全选 REALITY 时默认 HTTP，否则 SplitHTTP
4. XHTTP 独立给出一个选项填 querystring，可等价配置所有参数，分享链接会支持这个 querystring，不设其它参数
5. XGRPC 也是独立给出一个选项填 querystring，同上

[RPRX]

@mmmray 你可以直接把代码加到这个 PR 里并改个标题

[RPRX]

说下“上下行分离”，虽然 XHTTP 有这个能力，但我更想把这个能力加给 VLESS，从而不限制传输层，虽然 XHTTP 哪都能用

好处可以是“透传”，即我计划以后 VLESS 互转时，如 VLESS 自带加密中转 VLESS TLS/REALITY 时可以原样转发内层 VLESS 裸协议，这包括“上下行分离”的 UUID、XUDP 的 Global ID、时间戳、flow seed 等，或者可以配置只转发一部分，只是初步的想法

由此带来了“打通最初一公里”，即由 VLESS 自带加密取代 Shadowsocks，本来不想把前者弄成全随机数，现在得 reconsider 了

[RPRX]

vless随机数和shadowsock有什么区别啊

除了上面提到的那些东西外，最大的区别是 VLESS 自带加密有公私钥，类似于 REALITY 的 Session ID，还有其实能开 XTLS 裸奔

[RPRX]

@mmmray 进展如何

[mmmray]

@RPRX sorry, i didn't have time to focus. Soon 😓

[RPRX]

我感觉 XHTTP 还是不能默认兼容原 HTTP，否则会被没有 header padding 连累，服务端应该加个选项检查有没有 x_padding

[RPRX]

或许服务端会检查 x_padding 是否在 xPaddingBytes 范围内

[RPRX]

鉴于形势有变化，以及此前决定 XHTTP 不应默认兼容原 HTTP，打算先合了这个 PR，再放个大招，晚些时候再更名为 XHTTP

[RPRX]

先别急着 24.10.30，给我一天时间看看能不能放个大招