lostinqueens
asked on
Can't Get a Response Using URLConnection After Upgrading from JDK1.3 to JDK1.4
We've been frustrated with this problem for days and I'm running out of ideas. We have a servlet running under JDK1.3 and Tomcat 4.0.6 on a Windows 2003 server. We need to upgrade it so that we can talk to a server with an EV SSL cert. We thought this would be a slam-dunk, but after we recompiled in JDK1.4 and made the necessary tweaks to account for the JDK1.4 changes, we can't use URLConnection to the https or http port of an external site. We tested making a simple http connections to yahoo.com and google.com and nothing comes back. When we use our code to make an http connection to an internal site, everything looks good.
This feels like a firewall issue, but we can't get our heads around why a firewall is preventing responses from an internal request. We're using a CISCO ASA 5505 firewall and see nothing in the logs that jump out at us.
We're stumped. Is this a jdk issue? Why was this working perfectly in jdk1.3 and can't work in jdk1.4?
Any suggestions? We've exhausted all our ideas. Thanks.
This feels like a firewall issue, but we can't get our heads around why a firewall is preventing responses from an internal request. We're using a CISCO ASA 5505 firewall and see nothing in the logs that jump out at us.
We're stumped. Is this a jdk issue? Why was this working perfectly in jdk1.3 and can't work in jdk1.4?
Any suggestions? We've exhausted all our ideas. Thanks.
don't know if this will work, but try the URL with and without the ending slash
what response code are you getting?
Are you specifying the proxy?
http://www.rgagnon.com/javadetails/java-0085.html
I remember in some cases when I was trying to connect to outside
with Java it didn't want to do it without specifying proxy.
I think more recently I haven't encountered that issue,
maybe they changed something in our company,
but there were times when I could not do it directly.
There were some possibly minor changes in UrlConnection behavior between JDK 1.3 and 1.4. You need to post the exception you're getting, and the code with the line number noted in the exception for us to help solve the problem.
It's conceivable your jre network settings have not been replicated for your new jre. They are not replicated automatically
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for posting the solution. Next time -- post the exception and your code, and we'll be able to help.
>>
With http/1.1, the data comes back in chunks and thus, the content-length header does not provide information on the entire response. We modified our code to no longer look at content-length header but instead continue to read the response we receive until there is no more response and we know we've captured everything.
>>
Two points there:
a. The Content-Length header should report on the length of what is requested whether it's chunked or not, whichever version of HTTP
b. You can't rely on Content-Length being set, whichever version of HTTP
You thus need to read to EOS every time
With http/1.1, the data comes back in chunks and thus, the content-length header does not provide information on the entire response. We modified our code to no longer look at content-length header but instead continue to read the response we receive until there is no more response and we know we've captured everything.
>>
Two points there:
a. The Content-Length header should report on the length of what is requested whether it's chunked or not, whichever version of HTTP
b. You can't rely on Content-Length being set, whichever version of HTTP
You thus need to read to EOS every time
ASKER
Not an easy problem to track down. Hopefully, few have suffered with this issue as long as we did.