Как Jetty Websocket говорит на том же языке, что и JavaScript Websocket - PullRequest
0 голосов
/ 07 апреля 2020

Я написал Jetty Websocket Client, который подключается к удаленному серверу и пытается отправить JSON запросов. Сервер отклоняет запросы как недействительные и закрывает мое соединение. Тем не менее, когда я посылаю точно такой же JSON поверх Javascript клиента, он работает просто отлично. Итак, теперь я остаюсь, почесывая голову. Это кодирование Джексоном 2 JSON против JSON .stringify ()? (diff показывает два JSON выхода одинаково, без различий). Это другая конфигурация по умолчанию между Javascript Websockets и Jetty? Я определенно что-то упускаю, ударяя головой о стену.

Java Боковой фрагмент:

final String wsAddress = "ws://" + wssUrl + "/ws";
    final WebSocketClient client = new WebSocketClient();
    final WSEventSocket socket = new WSEventSocket(loginRequest);
    try {
        client.start();

        final ClientUpgradeRequest request = new ClientUpgradeRequest();
        final URI wsUri = new URI(wsAddress);

        logger.info("Connecting to {}", wsUri);
        final Future<Session> session = client.connect(socket, wsUri, request);

        final String requestjson = mapper.writeValueAsString(wsRequestPojo);
        final Future<Void> fut = session.getRemote().sendStringByFuture(requestjson);
...

Javascript боковой фрагмент:

var wsRequestJson = {...Use output from Java Side...}
var mySock = new WebSocket("ws://" + wsocketUrl + "/ws");
mySock.onmessage = function(evt) { console.log(evt.data); }; mySock.onclose = function() { console.log("CLOSED"); };
mySock.send(JSON.stringify(wsRequestJson));

Сторона Javascript работает отлично, сторона Java неправильно кодирует данные. Я пробовал множество таких вещей, как JSON для байтового массива и тому подобное. Я проверил обе транзакции и вижу толчки WebSocket и ответы. В Java я вижу полезную нагрузку, которая выглядит точно так же, как JSON, и Wireshark расшифровывает ее. В пакетах Javascript я вижу какой-то тип закодированных данных \ 214P \ 311n \ 3020 \ 024 ... Я прочитал немного о замаскированных полезных нагрузках, и оба клиента отправляют замаскированные полезные нагрузки с помощью маскирующих ключей, возможно, это как-то связано с этим ?

Есть идеи, как заставить сторону Java Jetty кодировать данные подобным образом? Или даже какой тип кодирования используется стороной Javascript? Я, наверное, уже слишком много думаю об этом ...

Спасибо!

1 Ответ

0 голосов
/ 07 апреля 2020

Как сказано @Joakim Erdfelt в комментарии выше, сторона Javascript использует Se c -Websocket-Extension: permessage-deflate по умолчанию. Возможно, это не лучший способ установить его, но я обновил свой код Java, добавив:

request.addExtensions(ExtensionConfig.parse("permessage-deflate"));

Обновленный фрагмент кода:

final String wsAddress = "ws://" + wssUrl + "/ws";
    final WebSocketClient client = new WebSocketClient();
    final WSEventSocket socket = new WSEventSocket(loginRequest);
    try {
        client.start();

        final ClientUpgradeRequest request = new ClientUpgradeRequest();
        request.addExtensions(ExtensionConfig.parse("permessage-deflate"));
        final URI wsUri = new URI(wsAddress);

        logger.info("Connecting to {}", wsUri);
        final Future<Session> session = client.connect(socket, wsUri, request);

        final String requestjson = mapper.writeValueAsString(wsRequestPojo);
        final Future<Void> fut = session.getRemote().sendStringByFuture(requestjson);
...

Работает как шарм! Спасибо!

...