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
Bare socket implementation & proxy support #88
Comments
When you talk about the socket interface do you mean the server or the client side? |
On Thu, 3 May 2012 09:22:17 -0700, David Rohmer wrote:
I'm using it on the client side (actually I'm using Cheers, |
i never needed to authenticate to a proxy when using websockts and also did not considered it during development even though it is covered by the protocol specification http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#page-17 So sooner or later i will take care of it. Regarding this blogpost: Someone discovered that nonblocking io consumes more memory than blocking one...by use of his smart mind and fancy inspection tools. He probability also thinks of wappers as an antipattern because of performance loss duo avoidable function calls. In case of my humble english could not stop you from despising nio you will probbably want your non nio websocket :) Probably someone will have to implement such a non nio client then. It would be great if that someone would be you. But currently there is not so much you can do because the IO related stuff is not yet 100% separated from the rest. EDIT: I highly likely can not lock horns with the author of that post in such topics also its fun to act as if :) |
When I originally wrote this lib, I started off with the regular Anyways, I'm not speaking for David here, but I doubt this lib will ever have a version that doesn't use non-blocking IO. |
On Sat, 5 May 2012 23:07:03 -0700, Daniel Wu wrote:
Thanks for all the replies.. For my purposes I only want one or possibly two WebSockets so the I originally started trying to write a replacement SocketChannel class I then started to hack some code into the WebSocket library to support CONNECT :80 HTTP/1.1 and then eat up the HTTP/1.1 Connection Established. message and then resume processing as per usual. With SOCKS it is http://en.wikipedia.org/wiki/SOCKS#Protocol it's still just a case of sending one write and expecting one read and I haven't quite got this working yet though.. basically I am having Cheers, |
Sorry, Rob, I realized I replied too fast and deleted my comment but you still saw it:-). My fault, SocketChannel does not support proxy and we have to tunnel it. Hopefully this can help you a little bit: |
Long time since the last reply. Any progress here? |
We don't have proxies yet but there is progress :) It can be easily implemented the same way ssl has been implemented: You derive a new class from WrappedByteChannel ( just like SSLSocketChannel2 does) which performs the proxy stuff.
I think i will have implemented it within the next month. |
Thanks for the update David. Will look into this and try to implement proxy support. I am also considering using an embedded Jetty server in my application to serve websocket content. Will let you know what I eventually come up with. Thanks & regards, From: David Rohmer [mailto:notifications@github.com] We don't have proxies yet but there is progress :) It can be easily implemented the same way ssl has been implemented: You derive a new class from WrappedByteChannel ( just like SSLSocketChannel2 does) which performs the proxy stuff. CONNECT example.com:80 HTTP/1.1 I think i will have implemented it within the next month. — This email message may contain proprietary, private and confidential information. The information transmitted is intended only for the person(s) or entities to which it is addressed. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be illegal. If you received this in error, please contact the sender and delete the message from your system. Mu Sigma takes all reasonable steps to ensure that its electronic communications are free from viruses. However, given Internet accessibility, the Company cannot accept liability for any virus introduced by this e-mail or any attachment and you are advised to use up-to-date virus checking software. |
@Davidiusdadi ,I have also used Java-WebSocket in my project, and need to use proxy. Does the client support proxy now? |
Until now there has been no proxy support. But i just introduced basic proxy support in 76d1206.
I just copied the scheme it from http://tools.ietf.org/html/rfc6455#section-4.1 and did not even tried out if the code works since i currently do not have a proxy at hand. In order to get better proxy support i would like you to take a look at Lets stay in contact to get proxy support working as soon as possible. |
compile: @Davidiusdadi ,seems that the class DefaultWebSocketClientFactory is missed...Can not compile with the latest codes |
ops, seems i forgot to commit that file. i will push it after work around 8 pm GMT+1 |
Nice! You rock! I'm going to start playing with this immediately. I'll get back to you on results. Edit: I'll be verbose in describing what I'm seeing because I may not solve this myself and want to share everything I've done, just in case I hit a dead-end. I'll consolidate this later if need be. After some initial testing ON ANDROID, I think your stuff is working fine, but either some proxy programs like fiddler and charles are having problems with websocket or the Android proxy layer is inserting a rogue colon into the GET line. I can't figure out which yet, but I will find the cause. I single-stepped through your code, but I couldn't find the cause in your code, and it looks like you are creating the HTTP Headers fine. So I suspect the issue is outside your code. Charles 3.6.5 doesn't seem to support SSL websocket or websocket in general. I tried using both version 8 and 13 (DRAFT_17). For SSL websocket, and then went to Proxy > Proxy Settings > SSL and check "Enable SSL proxying" then add the correct websocket SERVER and port under Locations. I used "*" for port. And I couldn't get websocket to proxy properly through Charles even off of Chrome and Firefox using Javascript, so Charles is obviously busted. Fiddler 4.4.4.0 is doing something strange and seems to think there is an extra colon after the GET line (but Charles isn't seeing that, so I think it's a Fiddler bug). I am pretty sure Java-Websocket isn't adding this since I'm single-stepping through. So I'm still looking into this and will probably fire up Wireshark on both the Android and computer and try to figure out what's going on. I suspect it's Android's proxy layer. I tried both websocket protocol 13 and 8. This is what Fiddler is showing, coming from Java-Websocket on Android to Fiddler proxy on my desktop (notice the colon at the end of the Get line - I ran through websocket code line by line and couldn't see this in the buffers or ascii arrays, so I don't suspect this is java-websocket doing it): VERSION 8: CONNECT SERVER_NAME_OMMITTED:81 HTTP/1.1 VERSION 13: CONNECT SERVER_NAME_OMMITTED:81 HTTP/1.1 Edit: I found out through wireshark later that Fiddler is adding the port on the Host header. Update: For comparison, these are the headers being sent by Chrome: Update: So there definitely is no colon in what Wireshark is receiving on the proxy server, so I would suspect Fiddler doesn't like the ordering of HTTP headers, or the content of the headers, or something like that. Here's what Wireshark shows for the proxy packets. One thing that really stands out is the positioning of Upgrade:Websocket not matching the RFC or the example above http://www.rfc-editor.org/rfc/rfc6455.txt In both cases, it looks like Upgrade: websocket should be called before Connection: Upgrade. Now, I'm looking at the draft functions like Draft_75::postProcessHandshakeResponseAsServer and it looks like at least in some cases, it's pushing it in the right order, but maybe they are ending up getting reordered later on, or maybe running through different logic. I'm debugging it now. Update 2: Upgrade:websocket is definately out of order due to a Map being used in postProcessHandshakeResponseAsServer but that isn't the cause of the issue. Albeit something that should be fixed. Update 3: I noticed in Wireshark that the Host header in the CONNECT request is missing /r/n/r/n at the end, like Chrome sends. Fiddler was also complaining that the Host header doesn't match the CONNECT hostname. I think there could be two causes: the lack of port on the Host or the /r/n/r/n. However, I believe the port is optional in HTTP (would need to double-check) and even the RFC doesn't show a port on the Host: header, so I suspect it's the lack of /r/n/r/n. Wireshark data below (hostname ommitted) Update: Alright, so I solved part of the issue, and now Fiddler is no longer inserting the colon, however I'm still not getting it to send/receive messages through websocket when proxied (yet Chrome has no issue through Fiddler, and I have no issue when not proxied). Anyway, the updated code for WebSocketClient.java . Fiddler didn't like the port not being on the end of Host, and since it's optional, it doesn't hurt to use it. The other important thing was \r\n\r\n needed at the end (I also changed \n to \r\n after HTTP/1.1 to have a proper end of line) I'll check it in when I've solved the other issues. WebSocketClient.java line : 414
Edit: I figured out what else was going wrong with the proxy. When websocket sends the proxy CONNECT, the server responds with Connection Established, so if the library receives a Connection Established response, it needs to ignore it and wait for the next response. But acceptHandshakeAsClient is treating it like it should be "Switching Protocols", which will be the next response. |
Update: As a reminder, Fiddler proxy will work now but Charles Proxy doesn't seem to handle websocket for any clients. |
…TallNate#88, TooTallNate#155, TooTallNate#167, TooTallNate#175, TooTallNate#177, TooTallNate#187) (changes not yet fully tested)
…TallNate#88, TooTallNate#155, TooTallNate#167, TooTallNate#175, TooTallNate#177, TooTallNate#187) (changes not yet fully tested)
Hi, i have recently started to use this library for websocket connection and i like it. I would like to continue using it but i have stumbled into a problem. My websocketclient is behind a proxy that needs user authentication and i didn't find any documentation or examples on how to set user and password for proxy. Where can i find some guidance if it is posible to setup user and posible and how. Thank you. |
Same here. Bump. |
I have a proxy server which have user and password but I am not sure how to add them in ExampleClient as it only accepts InetSocketAddress in setProxy. Please help |
I'm going to close this due to changes in the codebase since 2012 and general inactivity in this thread. Feel free to open new issues about specific aspects of proxy support and mention this issue if relevant. |
Is it sufficient to say that from https://github.com/TooTallNate/Java-WebSocket/wiki/Using-the-WebSocket-through-a-http-proxy, proxy support is there in this library with exception to (HTTP) proxy with (user + password) authentication? Although RE: @shuckc's comment, anyone know if it works for Android or just in (desktop) Java? For Java, there seems to be a platform limitation that was fixed a while back (in Java 8?). But not aware of anything similar for Android, there's no mention of the issue or whether there is or isn't HTTP proxy support for sockets in Android. Just asking as it seems we've encountered the mentioned Java limitation error using this library with HTTP proxy specified on Android. I guess for Android, one has to refer to #672. |
This isn't really a 'bug' per-say, but it would be really nice to have this library implemented on top of the regular java Socket interface rather than the java nio one because the nio stuff doesn't work with proxy servers http://blog.tsunanet.net/2010/08/java-nio-and-overengineering.html
The text was updated successfully, but these errors were encountered: