服务器响应错误-101,websocket - 响应代码不是101：200 - 握手错误(websocket - Response code was not 101: 200 - Handshake ...

websocket - 响应代码不是101：200 - 握手错误(websocket - Response code was not 101: 200 - Handshake error)

我运行的java桌面应用程序充当websocket通信中的客户端。

服务器代码(webservice)部署在AWS上的tomcat上。

当我尝试在本地运行代码，桌面应用程序和tomcat服务器时，它工作正常。

当我将我的桌面应用程序指向生产URL时，部署在AWS上的tomcat上，我得到以下异常。 即使我尝试使用excelsior jet创建.exe文件，但在运行.exe文件时仍然存在同样的问题。

例外

ex = (javax.websocket.DeploymentException) javax.websocket.DeploymentException: Handshake error.

响应代码不是101：200

我在Netbeans上运行，但在调用服务器端点时失败了。

这些是我用于桌面应用程序的库。

I have my java desktop application running which act as a client in websocket communication.

Server code (webservice) is deployed on tomcat on AWS.

When i try to run code locally, both desktop application and tomcat server, it works fine.

The moment i point my desktop application to production url, deployed on tomcat on AWS, i get below exception. Even i tried creating .exefile using excelsior jet, but still same issue while running .exe file.

Exception

ex = (javax.websocket.DeploymentException) javax.websocket.DeploymentException: Handshake error.

Response code was not 101: 200

I am running on Netbeans, but it fails while calling server endpoint.

These are my libraries used for desktop application.

原文：https://stackoverflow.com/questions/37421118

更新时间：2020-02-04 23:23

最满意答案

我找到了一个解决方案

I was missing a port after hostname,

我正在使用的网址是，

WS：//主机名/ endpointname

而不是这一个

WS：//主机名：端口/ endpointname

默认情况下，如果Tomcat在端口：80上运行，则无需在url中提供端口，但我将tomcat更改为8080端口。

I found a solution,

I was missing a port after hostname,

URL i was using was,

ws://hostname/endpointname

instead of this one

ws://hostname:port/endpointname

By default if Tomcat is running on port:80, no need to provide the port in url, but i changed my tomcat to 8080 port.

相关问答

在WebSocket连接上，您不需要101 Switching Protocols状态响应。 获得200状态响应可能意味着请求未到达WebSocket Handler。 我还会查看dev-tools，并检查响应是否有任何WebSocket握手头。 如果有，我会认为这是模块的问题。 否则它可能是你的配置。 On a WebSocket connection you want a 101 Switching Protocols status response. Getting a 200 status

...

完成！ 从http://blog.honeybadger.io/building-a-simple-websockets-server-from-scratch-in-ruby/找到答案，它的工作完美！ 代码： public ClientSocket(Socket socket) {

try {

this.socket = socket;

this.input = new BufferedReader(new InputStreamReader(socket

...

回答我自己的问题。 感谢雷米Lebeau！ 握手被包裹在一个Websocket框架中。 这违反了RFC 5455 。 所以握手直接需要通过套接字发送。 Answering my own Question. Thanks Remy Lebeau! The Handshake was wrapped in a Websocket frame. This violates RFC 5455. So the handshake directly needs to be send over the sock

...

我找到了问题并解决了它。 这是问题，在我的ProxyPass中，我正在将wss传递给wss。 对我而言，这应该是ws ws。 我的旧代码(错误的)是 ProxyPass "/wss/" "wss://localhost:9090/wss"

我的新代码(正确的)是 ProxyPass "/wss" "ws://localhost:9090"

I found the issue and solved it. Here was the issue, in my ProxyPass I was p

...

服务器违反了WebSocket协议。 Chrome很可能在版本20中更加正确地遵守该标准，并且揭示了服务器中的错误。 问题在于服务器在响应中发回“Sec-WebSocket-Protocol”头，但这只有在客户端在请求中发送相同头时才合法。 如果客户端没有发送Sec-WebSocket协议，那么服务器应该在响应中省略标题。 请参阅rfc6455第4.2.2节中的第22页上的/ subprotocol / description The server is violating the WebSock

...

根据https://tools.ietf.org/html/rfc6455#section-4.1 一旦发送了客户端的打开握手，客户端必须等待服务器的响应，然后再发送任何其他数据。 客户端必须按如下方式验证服务器的响应： 如果从服务器收到的状态代码不是101，则客户端根据HTTP [RFC2616]过程处理响应。 特别是，如果客户端收到401状态代码，则可能会执行身份验证; 服务器可能使用3xx状态代码重定向客户端(但客户端不需要遵循它们)等。否则，请按以下步骤操作。 第4.2.2节详细说明：除了

...

我找到了一个解决方案 I was missing a port after hostname,

我正在使用的网址是， WS：//主机名/ endpointname 而不是这一个 WS：//主机名：端口/ endpointname 默认情况下，如果Tomcat在端口：80上运行，则无需在url中提供端口，但我将tomcat更改为8080端口。 I found a solution, I was missing a port after hostname,

URL i was using was,

...

我找到了解决问题的可能方法。 通过Eclipse，我可以将Java项目Export到一个可运行的jar(将库“打包”到jar中)。 然后使用java -jar 运行它将在服务器上运行，并且与本地计算机上的功能相同。 但是，我注意到一些性能问题(启动缓慢)，所以我不认为这是最好的解决方案，但它是一个解决方案。 I figured out a possible solution to my problem. Through Eclipse, I can Export the

...

我通过将我的Glassfish版本更新到4.1.1(版本1)解决了这个问题，原始版本已经很老了(2014)。 I resolved this by updating my version of Glassfish to 4.1.1 (build 1), the original build was quite old (2014).

你不应该用钥匙回答吗？ 尝试在响应中添加Sec-WebSocket-Accept：sha1(Sec-WebSocket-Key +魔术字符串) shouldn't you respond with the key? try to add Sec-WebSocket-Accept: sha1(Sec-WebSocket-Key + magic string ) on your response