HTTPS with Applet over Proxy Issue
An applet using HttpURLConnection within a Java Applet. The Connection is formulated 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, my understanding is 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 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 arrives, 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
