-
Notifications
You must be signed in to change notification settings - Fork 42
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
Comments
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. |
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. |
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". |
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. |
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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: