[saurik]

FWIW, I do get that it is its own method and I understand the intent of the specification (and thereby why it "wouldn't matter" in that worldview), but it feels weirdly non-HTTP for this functionality to not be treated as a resource... but like, I guess "fair enough" in that (looking at it again) the existing old-school proxy CONNECT method also has this flaw :/. I just feel like people should be able to easily "mount" functionality onto their website into a folder, and by and large most HTTP methods support this, with the ability to then take that sub folder and internal-proxy it to some separate backend origin server (as like, I would want to take the flows for anything under /secret/folder/--whether GET or PUT or PROPPATCH or CONNECT-IP--and have my front-end http terminator be able to transparently proxy them, without having to understand the semantics of the method; it could very well be that I am just living in a dream of trying way too hard to be fully-regular in a world dominated by protocols that prefer to define arbitrary per-feature semantics ;P).

I guess I am also very curious why you aren't defining this over WebTransport (which would allow it to be usable from websites--verified by systems like IPFS--to build e2e-encrypted raw socket-like applications, as I imagine CONNECT-IP won't be something web pages will be able to use). (For anyone who reads this and finds this thought process "cool", talk to me about Orchid some time, where I do e2e multi-hop VPN over WebRTC ;P.)