Open PoneyClairDeLune opened 1 week ago
https://github.com/XTLS/Xray-core/pull/3832
And somehow the browser dialer of SplitHTTP is implemented via WebSocket instead of
fetch
request in either direction.
关于这个我想起来了,因为初版 browser dialer 写于 2021 年,而 chromium 在 2022 年才支持 streaming requests with fetch
并且 websocket 没有任何同源限制,不过问题不大,https://github.com/XTLS/Xray-core/pull/3830 加了跨域 header 就没问题了,话说加跨域 header 前竟然也能用
刚又仔细看了一眼发现自己已读乱回了
https://github.com/XTLS/Xray-core/blob/main/transport/internet/browser_dialer/dialer.go#L35
Went through the Go code for the browser dialer today. Not sure what purpose does the CSRF token serve, but if they're utilized to reject local scanning initiated from websites, an origin filter should suffice. Suppose a random website initiates a WebSocket connection to the browser dialer, but no matter how they try, the Origin
header will always be set, thus the same effect could be achieved by simply rejecting WebSocket connections with a mismatched Origin
header.
Another thought: Maybe the browser dialer page could benefit from some visual overhaul...
A continuation of #3832. Aimed at maximizing throughput and minimizing resource consumption on the browser side, and also potentially allowing arbitrary headers with the browser dialer.
Prerequisites
This draft is designed with the following assumptions.
Design
Still not fleshed out. Critiques are welcomed!
Web routes
WS /control
The control plane. This is the only place where any form of processing can happen with all possible latest web features. Xray can command the browser dialer on what and how to connect through it. If request bodies from Meek-like transports are not streamed, this should also carry the body of the request.
Message structure
uint32
)Commands
WS /data?id=<socketId>
For Chrome 124 and later. Where contents of WebSocket connections are passed through without any processing.
WebSocketStream
- MDNGET/POST /data?id=<socketId>
For Chrome 105 and later. Where contents of all web-compliant connections are passed through without any processing. Has the exact same use as above, only that for each duplex connection, a get-post pair is created due to browsers refusing to support HTTP/2 cleartext.
Send
ReadableStream
in request body - caniuse.comBrowser-side behaviour
WebSocketStream
WebSocketStream
pass-through 1WebSocket