[feature request] Add h2c to XHTTP.

[deepsm0ke]

Hi.
Thanks for publishing vless encryption for strong data encryption even in non-TLS mode.

I think now is a good time to build and add h2c to XHTTP, but there should be a requirement for vless encryption to be enabled in this mode. The reason and argument for using h2c in XHTTP compared to other transport layers like ws/hu/grpc, is the existence of header padding, as well as the nature of http itself and the use of xmux in h2c can be very good points even in non-TLS mode (I emphasize again, provided that vless encryption is enabled).

I would be happy to hear xray team and people' opinions.

[Fangliding]

dup #4875

[RPRX]

XHTTP 的 header padding 只有在外层是 TLS/REALITY 时才有意义，不然都被看光了，padding 与否没区别

不过随着 VLESS 出了 Encryption，这个话题可以继续，reopen 作为默认禁止公网未加密流量的 reminder，2026 就禁吧

[Fangliding]

XHTTP 的 header padding 只有在外层是 TLS/REALITY 时才有意义，不然都被看光了，padding 与否没区别

不过随着 VLESS 出了 Encryption，这个话题可以继续，reopen 作为默认禁止公网未加密流量的 reminder，2026 就禁吧

他的意思是要加h2c 现在也没有h2c啊 没tls是h1 vless enc也不加密xhttp的东西

[RPRX]

我知道，但 2026 默认禁了公网未加密流量后，#4875 (comment) 提到的“这东西不安全”就不存在了

只要内层是 VLESS Encryption，攻击者去改外层明文 XHTTP 也不会影响被代理的数据的安全

[Fangliding]

那原issue的意思大概也是搭vmess用 我理解的不安全的意思是明文加上xhttp那堆显眼的参数露头秒 新的代理协议也不能改变这个情况
这难道说2026加h2c吗

[RPRX]

伊朗自有国情在，限速 TLS 却不管明文 HTTP，就是逼着你用，再加上伊朗有对时问题（我也不太理解这是个什么问题，好像因为默认采用什么计时标准导致时间戳差半天？@gfw-killer ），用不了需要对时的加密，结果都用明文 VLESS 了

我的意思就是以前开放的话会有很多人开始用 XHTTP h2c + plain VLESS，不安全，但是出了 Encryption 并禁了公网未加密流量就好了

[Fangliding]

vmess可以加个对时 但是一想到又有某人要自定义sockopt丢个dialer七了八糟的就头疼

[gfw-killer]

再加上伊朗有对时问题（我也不太理解这是个什么问题，好像因为默认采用什么计时标准导致时间戳差半天？@gfw-killer

Time difference is 1 Hour, It's because on 22 September 2022 Iran cancelled Daylight Saving Time (DST). Devices and Operation Systems with no newer update can't connect to VMESS (Even changing the time manually didn't worked in Android, only SB/Mihomo NTP works to fix VMESS in those Android devices)
But Encrypted VLESS should be fine, Thank you for this

But for H2C, I made the same Issue but VLESS had no PQ Encryption at that time
But now it's ready. I think it's a good time to support non-tls combinations. but limit to the Encrypted VLESS only

[deepsm0ke]

but limit to the Encrypted VLESS only

I agree with this part of gfw-killer's statement. When a client wants to connect using non-TLS, they must be required to use VLESS Encryption, otherwise the xray-core will not allow the connection.

[deepsm0ke]

@RPRX @Fangliding
I was wondering if it was possible to randomize the characters in the header padding and use other letters(a-z,A-Z,0-9,...) instead of just XXXXXXXXXX? Because without TLS, HTTP content like header show clear texted, And would make it easier to identify xhttp by GFW.

[RememberOurPromise]

I think it's a good time to support non-tls combinations. but limit to the Encrypted VLESS only.

之前不少使用workers搭代理的用户直接使用无加密VLESS/Trojan + ws，80端口裸奔
说了也不听的，有必要限制一下

[gfw-killer]

I was wondering if it was possible to randomize the characters in the header padding and use other letters(a-z,A-Z,0-9,...) instead of just XXXXXXXXXX? Because without TLS, HTTP content like header show clear texted, And would make it easier to identify xhttp by GFW.

There is no point in Padding when there is no TLS, so it should be removed when there is no TLS
But for CDN, yes it's helpful, but still not enough #5414 (comment)

之前不少使用workers搭代理的用户直接使用无加密VLESS/Trojan + ws，80端口裸奔
说了也不听的，有必要限制一下

This is what I'm saying #5067 (comment)
I can't find a link, but i remember RPRX said he will lock unencrypted non-tls inbounds and outbounds to Localhost only, but allows to unlock it using a Environment Variable
VLESS Encryption is well tested and is stable, every server and client updated and supports it
I think it's the time, I am waiting for RPRX

[deepsm0ke]

There is no point in Padding when there is no TLS, so it should be removed when there is no TLS But for CDN, yes it's helpful, but still not enough

@gfw-killer
Alright, I accept your point. But don’t you think that even without TLS, the GFW would still be able to identify XHTTP behavior and patterns later based on its headers? Requiring users to use VLESS encryption would be great, but in my opinion, the XHTTP pattern will still very likely be identifiable from its headers in the future.