我有一个需要访问Web服务的
Java应用程序(而不是一个小程序). Web服务的代理已经使用JAX-WS生成,似乎工作正常.在一种情况下,需要通过Web代理服务器(实际上是Squid 3.0)进行交流,该服务器设置为需要NTLM身份验证.
在Sun的JRE 1.6.0_14上运行,一切都可以正常访问HTTP网址,而不需要任何更改：内置的NTLM身份验证器可以无缝地进行.但是,如果Web服务URL是HTTPS URL,那么Web服务调用在Sun的代码之内就会失败：
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.lang.NullPointerException
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
... our web service call ...
Caused by: java.lang.NullPointerException
at sun.net.www.protocol.http.NTLMAuthentication.setHeaders(NTLMAuthentication.java:175)
at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:1487)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:164)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:896)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:230)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)
... 16 more
在Sun的bug数据库中查看这些类中的一些例外,但是它们似乎已经被修复了.有没有人遇到过这样的事情？有人有这个工作吗？
解决方法
经过一些调试,这似乎是JRE类库中的一个缺陷,特别是在sun.net.www.protocol.http.HttpURLConnection中.
在HTTP和HTTPS端点的情况下研究HTTP请求和响应表明,在成功的HTTP情况下,请求具有标头Proxy-Connection =保持活动,这在失败的HTTPS情况下丢失.阅读更一般来说,似乎有一些混淆是否应该使用“代理连接”或只是“连接”？
无论如何,值得注意的是,在HTTP的情况下,代码通过HttpURLConnection.writeRequests(),它包含以下代码段
/*
* For HTTP/1.1 the default behavior is to keep connections alive.
* However,we may be talking to a 1.0 server so we should set
* keep-alive just in case,except if we have encountered an error
* or if keep alive is disabled via a system property
*/
// Try keep-alive only on first attempt
if (!FailedOnce && http.getHttpKeepAliveSet()) {
if (http.usingProxy) {
requests.setIfNotSet("Proxy-Connection","keep-alive");
} else {
requests.setIfNotSet("Connection","keep-alive");
}
在通过HTTPS代理创建隧道时,没有这样的代码,这导致Squid在NTLM身份验证会话期间感到不舒服.
要解决这个问题,在HttpURLConnection.sendCONNECTRequest()中,我补充说
if (http.getHttpKeepAliveSet()) {
if (http.usingProxy) {
requests.setIfNotSet("Proxy-Connection","keep-alive");
}
}
就在之前
setPreemptiveProxyAuthentication(requests); http.writeRequests(requests,null);
我使用“-Xbootclasspath / p”标志将我修改后的HttpURLConnection.class注入到JRE中,现在它正常工作！不完全优雅,但我们是.
