Java Applet over Proxy Problem
- From: Gary M <gmaddr-usenet@xxxxxxxxx>
- Date: Fri, 03 Jun 2005 21:22:28 -0400
An applet using HttpURLConnection within a Java Applet. Snippet as follows:
HttpURLConnection urlConn = (HttpURLConnection)destURL
.openConnection( );
urlConn.setDoOutput( true );
urlConn.setDoInput( true );
urlConn.setUseCaches( false );
urlConn.setAllowUserInteraction( false );
urlConn.setRequestProperty( "Content-type","multipart/form-data" );
urlConn.setRequestProperty( "Content-length","" + parameters.length( );This works fine with numerous proxy servers and other network topologies, except one. The issue I am told occurs when we are trying to connect over https. For background, this causes the Java Plug-in to
* invoke the http CONNECT command * wait for the 200 OK indicating that the secure tunnel is established * then send the request securely.
Doing a packet trace shows that the above headers set in the code are actually being _included_ with the CONNECT. However the Java Plug (1.4.2_06) does not sent the body with the CONNECT. I am told this causes the proxy to wait for an entity that never arrive, because, on the other end the plug-in is waiting for 200 OK. After 8 secs the plug-in resets the connection and fails.
Packet traces on other proxies show the same content-length header being included, but they decide ignore it. From Googling I note some folks claim that this is expected, because CONNECT is non-entity enclosing. Doc's are scant on the CONNECT command. In some cases they seem to imply that no data should go with the CONNECT (making it non-entity enclosing), but later they state it supports data-pipelining, making the content-length relevant, as the CONNECT may well contain an entity.
Moreover, is the intent of Applet Framework to insulate the programmer from having to worry about issues like this? For example this Applet can and does connect to a myriad of HTTP/1.1 or 1.0 server through a proxy or not; in the case of no proxy or non secure proxy, the content-length header is valid as the request goes out in one go with associated headers. So writing the code as above, does not seem to be inherently flawed, IMO. <-- And that is a question too :).
I note there is an isProxy() method, but this can only be determined after connection (obviously) and parameters cannot be changed once the connection is made. So creating a dummy connection first is possible I suppose, but it seems a slippery slope to start coding for exceptions like this, unless absolutely necessary.
On the face of it, it could be argued that this appears to be a bug in the plug-in but with very little hits in google I am doubtful. To that end, does anyone have any thoughts or experience with either working around the problem (it would seem to be a pity to have to have a setting per client), or whether in fact this proxy server is being too draconian in its interpretation.
Thanks in advance,
Gary
Refs:
RFC2616 http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt
.
- Prev by Date: Right use for JTA transactions?
- Next by Date: Re: Text color in Windows console
- Previous by thread: Right use for JTA transactions?
- Next by thread: Number of tests per line of java code
- Index(es):
Relevant Pages
|
