Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support connecting through proxies #73

Open
catern opened this issue Aug 30, 2020 · 7 comments
Open

Support connecting through proxies #73

catern opened this issue Aug 30, 2020 · 7 comments

Comments

@catern
Copy link

catern commented Aug 30, 2020

emacs-websocket doesn't support connecting through HTTP proxies. It probably should read url-proxy-services and use that to automatically go through an HTTP proxy for the websocket connnection if one is configured.

I don't know the websocket protocol but I'm fairly motivated to get this working so I might try doing this myself - do you think it will be much work?

@catern
Copy link
Author

catern commented Aug 30, 2020

I got some extremely hacky modifications for this working, where, when a proxy needs to be used, I synchronously connect to the proxy, send a CONNECT, call gnutls-negotiate, then proceed with websocket.el's normal processing. I'll post the patch here in a few days once I feel a little more comfortable with it. But for now it seems to work.

@ahyatt
Copy link
Owner

ahyatt commented Sep 1, 2020

I'll have to think about this - it seems like a good thing to have, but it'd be nice to do this in a way that wouldn't complicate the main websocket code. Let me know when you have a patch, and I'll take a look.

@catern
Copy link
Author

catern commented Sep 1, 2020

Here's the patch: #74

I did a lot of digging into url.el's proxy support, and was able to reuse a fair bit of functionality - the main thing that I couldn't reuse is url-https-proxy-after-change-function, but maybe there's a way... it would be nice if url had a way to say, "establish the connection, including proxy setup, then send the request, then just call my process filter and get out of the way".

@ahyatt
Copy link
Owner

ahyatt commented Sep 3, 2020

Interesting. I don't think this is that hacky, however I'll have to think about this.

Also, do you have signed FSF papers? This probably is small enough that it doesn't matter, but I need to verify this if you don't.

@catern
Copy link
Author

catern commented Sep 3, 2020

Well, the main hacky bit is the sleep-for. Everything else is fine I suppose, but relies on that core hackiness...

I don't have signed FSF papers, but I've been meaning to for a while, so I'll go ahead and do that now, regardless of whether this is small enough or not.

@dickmao
Copy link

dickmao commented Nov 14, 2020

How does failure manifest itself? It would seem from catern's changes that websocket-open simply can't connect, and that some kind of initial negotiation with the proxy is required before opening the network stream to the intended target. I have very little experience with proxies -- I barely know what they're for other than to make our lives more complicated. :)

In regard to millejoh/emacs-ipython-notebook#754 , the websocket from the emacs client does get through, it's just the remote server doesn't see an auth token in the json message. That is quite a mystery, but at first glance this PR wouldn't remedy that, or would it? A proxy presumably would not strip data from a message.

@ahyatt
Copy link
Owner

ahyatt commented Nov 15, 2020

Yes, I think this sounds like a different problem. This problem should result in connection issues, not authentication issues. That said, I haven't tried replicating this - I don't have a proxy, or a websocket server that does auth checks using json. And I'm also not that knowledgeable about proxies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants