mmmray

> The current Eclipsed implementation cannot penetrate CDNs buffering request bodies The selling point of existing Meek implementations so far has been that it can pass arbitrary HTTP "middleboxes", not...

I am increasingly convinced that HTTP SSE/streaming for download, and individual HTTP requests for upload, just like RPRX said, is the way to go. With as little extra complexity as...

I have written a HTTP tunnel now in Rust [here](https://github.com/mmmray/minidialer?tab=readme-ov-file#split-http-tunnel). setup is like this: 1. for each new TCP session, client rolls a UUID. client opens streaming HTTP response at...

> Still, even that is incompatible with many CDN. I found that many CDNs and apache installations buffer response bodies, but it can be fixed with the response header `X-Accel-Buffering:...

I think this issue and #2162 #3333 are "done". The "splithttp" transport implements some of these ideas and ultimately serves the same purpose as meek. Since there are a lot...

In https://github.com/XTLS/Xray-core/pull/3884: Let's try to use SSL In this issue: How about quantum-resistance?

> In fact, after REALITY, I don’t really want Xray to take care of the certificates This is a really weird usecase I just thought of, and I have not...

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...

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~~

`?upload=normal` / `?upload=chunked`