HACK: add support for using a proxy for wss connections #74
Conversation
| (let ((url-http-after-change-function) | ||
| (url-current-object url-as-http)) | ||
| (url-https-proxy-connect plain-conn)) | ||
| (sleep-for 0.5) |
There was a problem hiding this comment.
Why is the sleep needed? Can we instead check plain-conn?
There was a problem hiding this comment.
We need to wait until we get a response to the CONNECT issued by url-https-proxy-connect. The proper (and only) way to do this is with a process-filter. I was just too lazy to hook up that additional possible state into the websocket.el process filter...
| (url-as-http (let ((url-as-http (copy-sequence url-struct))) | ||
| (setf (url-type url-as-http) (if (eq type 'plain) "http" "https")) | ||
| url-as-http)) | ||
| (proxy (url-generic-parse-url (url-find-proxy-for-url url-as-http (url-host url-as-http))))) | ||
| (if (eq type 'plain) | ||
| (make-network-process :name name :buffer nil :host host |
There was a problem hiding this comment.
Will this work with http proxies? I'd guess you would need to make the host different if it is a proxy?
There was a problem hiding this comment.
I'm not sure what you mean by "http proxies" - the code I have here only works with proxies that talk plain HTTP without encryption. (The gnutls-negotiate later on is for TLS with the websocket server)
There was a problem hiding this comment.
Sorry, I wrote something that didn't make sense.
The way I read this, it doesn't look like it would go through a proxy for unencrypted websockets. The logic testing for proxies is only execute if type is not 'plain.
There was a problem hiding this comment.
Right, this only works for wss:// at the moment. I didn't have a need for ws:// and didn't set up a testing environment for it. In theory it could be as simple as not doing the gnutls-negotiate.
| (url-current-object url-as-http)) | ||
| (url-https-proxy-connect plain-conn)) | ||
| (sleep-for 0.5) | ||
| (gnutls-negotiate :process plain-conn :hostname host)) |
There was a problem hiding this comment.
Is this all a standard sequence of actions for https proxy connections? How would we be sure this is correct?
There was a problem hiding this comment.
As far as I know it's pretty standard - I figured this out mostly by reading url.el.
We certainly could add a test for this. I looked briefly at https://tinyproxy.github.io/ and it looks like it should support proxying websocket connections. I just didn't get around to it because I wanted to figure out quickly if I could get this working against the internal corporate proxy that I wanted to access.
For me this "solves" #73 but it's very hacky...