It would then be weirdly important that a mis-authenticated CONNECT-IP then look the same as if CONNECT-IP were not implemented, as opposed to returning an authorization error of some kind (which seems weirder than hiding the method via the path).
True. But the path method has issues too, like, how would you implement that with HTTP 1.1? The "path" field is actually part of the target, so you would have to send the request like `CONNECT-IP https://remote-server/mount-point` which seems backwards. (EDIT: and also you still need to make sure you don't give the wrong kind of error if the path is wrong, like a 404 instead of a 501 not implemented or whatever)
As a possible solution for the discovery by authorization error problem, maybe a convention could be established where an authorization error is returned by default if CONNECT-* isn't configured.
Huh. It is possible that I simply didn't understand the spec, as I was (and am...) pretty sure that CONNECT-IP (at least at the HTTP semantics level) just takes a path (and only /)--like GET--without an associated "extra" authority, as it is creating an IP tunnel: there is no remote host (as there would be with an old-school CONNECT); like, what is the "target" here? I am just talking to the server and asking it to give me an IP bridge, right? What does "remote-server" represent to an IP tunnel?
