1

I'm implementing Jetty's WebSocket.OnTextMessage. When I receive message in onMessage(String), I can reply using Connection object that I acquire from onOpen(Connection) previously and the client receives it properly.

However when I want to push message from server (i.e. no initial message from client) using connection.sendMessage(String), the client does not receive it. It seems like the message is being buffered, but I can't find any method to flush it.

Does anyone know how to solve this issue? Perhaps I'm doing is incorrectly. This is what I did

public void onOpen(final Connection connection) {
    this.connection = connection;
}

Then on another event

public void onReceive(BytesXMLMessage bytesXMLMessage) {
    byte[] data = ((BytesMessageImpl) bytesXMLMessage).getData();
    String msgToClient = new String(data);
    this.connection.sendMessage(msgToClient);
    System.out.println("onReceive:" + msgToClient);
}

But the message never received by the client

Update: Found the pattern, the message will never be sent to client whenever it contains HTTP methods keyword such as GET, POST, PUT, HEAD, etc irrespective of whether it is uppercase or lowercase.

Is there anyway to mitigate this issue?

Update: This is the very simplified implementation of WebSocketServlet that can simulate the issue

package com.test.websocket;

import org.eclipse.jetty.websocket.WebSocket;

import javax.servlet.http.HttpServletRequest;
import java.io.IOException;

public class WebSocketServlet extends org.eclipse.jetty.websocket.WebSocketServlet {
    @Override
    public WebSocket doWebSocketConnect(HttpServletRequest request, String protocol) {
        return new WebSocket.OnTextMessage() {
            private Connection connection;
            @Override
            public void onMessage(String data) {
                try {
                    connection.sendMessage("Echo: " + data);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }

            @Override
            public void onOpen(Connection connection) {
                this.connection = connection;
            }

            @Override
            public void onClose(int closeCode, String message) {
                connection.close();
            }
        };
    }
}

And this is the web.xml

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
    <servlet>
        <servlet-name>EchoWebSocket</servlet-name>
        <servlet-class>com.test.websocket.WebSocketServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>EchoWebSocket</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>
4

3 に答える 3

2

HTTPメソッドキーワードを送信できない根本的な原因を見つけました。これは、開発マシンで実行されているAntivirus Kasperskyが、すべてのHTTPメソッドキーワードのネットワーク層でインターセプトしていることが原因であり、適切な標準HTTPプロトコル内で動作している必要があります。おそらく、まだWebSocketプロトコルをサポートしていません。

ユニットテストの作成を支援してくれた@jessemcconnellに感謝します。

于 2012-09-25T16:16:02.857 に答える
0

[edit]

I am unable to validate this with a unit test, I have the client side senting a message of "GET" and then the server side returning the same string and the client side receives it. If you have more information on it please open an issue with a way of reproducing at bugs.eclipse.org under the RT/Jetty project if you like.

At this point I am leaning towards and implementation issue on your side, if you can post some code to take a look at or something that might help.

This is the new test case as you described: http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/?id=494f7e48fcc20c51066cd91a6dac1d738cacb54e

于 2012-09-25T12:32:38.807 に答える
0

The websocket protocol was designed to try avoid looking like HTTP traffic. Specifically it applies a random mask to the payload of all frames sent from the client to the server so that it is highly unlikely that a websocket message can look like a HTTP request.

However the protocol does not mask payload sent from server to client, as the thinking was that there is likely attack vector that could be exploited with traffic in that direction.

I guess we did not consider that intermediaries like your firewall might be a little over rigorous in what they look for and block. I can't think why they are blocking such traffic as I can imagine it would also block things like XMPP messages with text like "DON'T FORGET TO GET THE MILK!". But it does... so the only real options are for you to:

  1. encode the payload content yourself and decode in the client.
  2. turn off the firewall (or detune it)
  3. get the firewall fixed.
于 2012-09-28T00:21:21.690 に答える