JDK-5075841 : HttpURLConnection through a proxy sometimes fails when keepalives are enabled
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0_01,1.4.2_05,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-07-20
  • Updated: 2006-12-18
  • Resolved: 2006-12-18
Related Reports
Duplicate :  
Relates :  
Description
Making a connection from an applet back to the server it came from will occasionally fail, with an AccessControlException for a SocketPermission connect,resolve of the proxy server, if the connection is proxied and keepalives are enabled . An example stack trace from the attached test-case webapp is:

java.security.AccessControlException: access denied (java.net.SocketPermission webcache:8080 connect,resolve)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
	at java.security.AccessController.checkPermission(AccessController.java:401)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
	at java.lang.SecurityManager.checkConnect(SecurityManager.java:1026)
	at sun.net.www.protocol.http.HttpURLConnection.proxiedConnect(HttpURLConnection.java:373)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(HttpURLConnection.java:364)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(HttpURLConnection.java:346)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:297)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:625)
	at sun.plugin.net.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:402)
	at ProxyTest.send(ProxyTest.java:135)
	at ProxyTest.runTest(ProxyTest.java:96)
	at ProxyTest.access$000(ProxyTest.java:8)
	at ProxyTest$1.actionPerformed(ProxyTest.java:58)
	at java.awt.Button.processActionEvent(Button.java:382)
	at java.awt.Button.processEvent(Button.java:350)
	at java.awt.Component.dispatchEventImpl(Component.java:3615)
	at java.awt.Component.dispatchEvent(Component.java:3477)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

to reproduce, deploy the attached war (i'm using iPlanet Webserver Enterprise 6.0sp5), then point your browser (i'm using Mozilla 1.4 with Java Plugin 1.4.2_02) at the root of the deployed webapp and click the "start" button. it will usually fail within a couple of hundred connections but you may need repeated runs as it is obviously timing related, it happens more frequently on a couple of production systems, perhaps due to the size of the data.

Note that the same thing happens if you run the test as an application with the default security manager enabled and a policy file that permits connecting to your server (see the run & policy files in the webapps classes directory).

This seems to have broken in release 1.4.0_01 (at least i cannot reproduce it with 1.4.0) and remains broken up to releases 1.4.2_05 and 1.5.0 beta2.

Comments
WORK AROUND disable keepalives either at the webserver end or by passing -Dhttp.keepalive to the JRE.
18-09-2004

EVALUATION Strange. The permission check looks bogus. We should trust proxies and not require a permission check at all. The question is why does the problem not occur more often. In fact, it has never been reported before. It seems that the code path is only encountered when a keep-alive connection is taken from the cache, but the connection gets closed (probably by the server) before we get to use it. This would be fairly uncommon. Need to look at the https code because it looks like it should happen more often in the https case. Should fix this as soon as possible after tiger fcs. ###@###.### 2004-07-22
22-07-2004