Netty 3.10.0.FINAL говорит: «Неверный формат версии: <! DOCTYPE»

Question

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

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

Я не получаю отклик в моей заявке вообще из-за этого. Netty выдает исключение, и все.

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

Когда я использую CURL для вызова службы, для которой возникла эта проблема, я получаю правильный ответ с надлежащей версией HTTP. Ниже приведены заголовки HTTP, которые завиваются. Я также получаю надлежащее тело, которое НЕ начинается с <!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 

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

Answer 1

Мы использовали https без установки опции withTls на клиенте 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); 
} 

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