Can't Get a Response Using URLConnection After Upgrading from JDK1.3 to JDK1.4

Posted on 2011-03-19
Last Modified: 2012-05-11
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 and 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.
Question by:lostinqueens
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
  • 2
  • +3

Expert Comment

ID: 35174019
don't know if this will work, but try the URL with and without the ending slash
LVL 92

Expert Comment

ID: 35174094
what response code are you getting?
LVL 47

Expert Comment

ID: 35174281

Are you specifying the proxy?

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.
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 27

Expert Comment

ID: 35175975
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.

LVL 86

Expert Comment

ID: 35183221
It's conceivable your jre network settings have not been replicated for  your new jre. They are not replicated automatically

Accepted Solution

lostinqueens earned 0 total points
ID: 35195127
Thanks for everyone's suggestions. We finally figured out our problem. With JDK1.3, only the http/1.0 protocol is used. So, when we made our request with JDK1.3, http/1.0 was used and the *entire* response was sent back at once with a content-length header. We were able to read the content-length header and know how big of a response we received.

With JDK1.4, either http/1.0 or http/1.1 can be used, but you can't decide which protocol is actually used. 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. We used ByteArrayInputStream similar to what's mentioned in this post:

I believe our code worked when testing against an internal server because the internal server saw the request as coming from the internal network so decided to use http/1.0, but when the same server saw a request coming from an outside network, it decided to chunk the response using http/1.1 and thus our code failed.

So, in the end, our problem was an http/1.0 vs. http/1.1 issue and a thinly documented change to URLConnection from JDK1.3 to JDK1.4.
LVL 27

Expert Comment

ID: 35195846
Thanks for posting the solution.  Next time -- post the exception and your code, and we'll be able to help.
LVL 86

Expert Comment

ID: 35196429
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

Author Closing Comment

ID: 35225502
Not an easy problem to track down. Hopefully, few have suffered with this issue as long as we did.

Featured Post

MIM Survival Guide for Service Desk Managers

Major incidents can send mastered service desk processes into disorder. Systems and tools produce the data needed to resolve these incidents, but your challenge is getting that information to the right people fast. Check out the Survival Guide and begin bringing order to chaos.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Introduction This article is the first of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article explains our test automation goals. Then rationale is given for the tools we use to a…
I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market.  Every year, Cisco displays cutting-edge technol…
Viewers learn about the “for” loop and how it works in Java. By comparing it to the while loop learned before, viewers can make the transition easily. You will learn about the formatting of the for loop as we write a program that prints even numbers…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question