Netty 3.10.0.FINAL говорит, что неверный формат версии: ‹!DOCTYPE

мы используем клиент Twitter Finagle, который использует Netty в качестве своего HTTP-клиента. Мы видим для одного из наших вызовов веб-службы, что Netty не может определить HTTP-версию ответа, что приводит к

2017-01-13 11:28:13,825 [finagle/netty3-1] WARN com.twitter.finagle.netty3.channel.ChannelStatsHandler ChannelStatsHandler caught an exception
java.lang.IllegalArgumentException: invalid version format: <!DOCTYPE

Класс Netty org.jboss.netty.handler.codec.http.HttpVersion пытается определить версию HTTP (HTTP/1.1, HTTP/1.0) на основе строки <!DOCTYPE. Это явно не сработает. Совпадение не выполняется, что приводит к исключению IllegalArgumentException, указанному выше.

Я вообще не получаю ответа в своем приложении из-за этого. Нетти выбрасывает исключение и все.

Мой вопрос в том, почему Netty может использовать <!DOCTYPE в качестве входных данных для соответствия версии HTTP в классе HttpVersion.

Когда я использую CURL для вызова службы, для которой возникает эта проблема, я получаю правильный ответ с правильной версией HTTP. Ниже приведены заголовки HTTP, которые возвращает curl. Я также получаю правильное тело, которое НЕ начинается с <!DOCTYPE. Это правильно сформированный ответ SOAP, начинающийся с <SOAP-ENVELOPE...

HTTP/1.1 200 OK
Date: Fri, 13 Jan 2017 12:25:14 GMT
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Connection: close
Transfer-Encoding: chunked

Я предполагаю, что неудачный вызов происходит из-за того, что какая-то промежуточная система возвращает «сломанный» ответ, который я не смог вызвать с помощью CURL. Итак, мой второй вопрос будет заключаться в том, возможно ли вообще, чтобы система возвращала ответ без версии Http, и думаю ли я здесь в правильном направлении.


person Julius    schedule 13.01.2017    source источник


Ответы (1)


Мы использовали https без установки параметра withTls в клиенте Finagle.

Решение для нас состояло в том, чтобы создать клиент Finagle, используя опцию com.twitter.finagle.Http.withTls(String hostName) и, в нашем конкретном случае, также установить контекст SSL Java на версию TLS 1.2:

SSLContext sslContext = null;
try {
    sslContext = SSLContext.getInstance("TLSv1.2");
    SSLContext.setDefault(sslContext );
} catch (NoSuchAlgorithmException e) {
    log.error("Failure getting ssl context", e);
}

После этих изменений проблема исчезла.

person Julius    schedule 14.01.2017