Netty 3.10.0.FINAL은 "잘못된 버전 형식 : <! DOCTYPE"

Question

을 사용합니다. Netty를 HTTP 클라이언트로 사용하는 Twitter의 Finagle 클라이언트를 사용합니다. 우리의 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는 예외를 던지고 그게 전부입니다.

내 질문에 Netty가 HttpVersion 클래스의 HTTP 버전 일치에 대한 입력으로 <!DOCTYPE을 사용할 수있는 이유는 무엇입니까?

CURL을 사용하여이 문제가 발생한 서비스를 호출 할 때 적절한 HTTP 버전으로 적절한 응답을받습니다. 다음은 뒤틀리는 HTTP 헤더입니다. 나는 또한 적절한 몸을 얻는다. 그것은 <!DOCTYPE으로 시작하지 않는다. <SOAP-ENVELOPE..으로 시작하는 올바른 형식의 SOAP 응답입니다.

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 시스템 내가 CURL으로 트리거 할 수 없었으므로는 '깨진'응답을 반환하기 때문에 실패한 호출이 발생한다는 것입니다. 따라서 두 번째 질문은 시스템이 HTTP 버전없이 응답을 반환 할 수 있는지, 그리고 여기에서 올바른 방향으로 생각하고 있는지 여부입니다.

Answer 1

Finagle 클라이언트에서 withTls 옵션을 설정하지 않고 https를 사용하고있었습니다.

우리의 솔루션은 TLS 버전 1.2로 자바의 SSL 문맥을 설정하기 위해, 우리의 특정한 경우, com.twitter.finagle.Http.withTls(String hostName) 옵션을 사용하여 변통 클라이언트를 만드는 것이었다과 : 문제가 사라 이러한 변경 후

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

.