Hello Devs,
I am a contributor to an open source project called GlazedLists.
Recently, it has become desirable for us to use the ant Get task to
download, as needed, jar files from a webserver in order to support a
"configurable" build system. The file in quesiton is
https://glazedlists.dev.java.net/files/documents/1073/24419/ktable.jar
The ant Get task fails to download ktable.jar from the link above. What
happens is, glazedlists.dev.java.net and a peer server,
www.dev.java.netredirect us back and forth between themselves in an
endless game of tag by
sending us HTTP result code 302. Eventually, Java's URL connection gets fed
up and throws an exception explaining that we have followed too many
redirects (20). The reason Java's URL connection receives infinite redirects
while normal web browsers allow you to download these files without problems
is that:
*Java's URLConnection DOES NOT send any collected cookies when it is
redirected*
and apparently web browsers do.
Put differently, ant's Get task is a thin wrapper around
java.net.HttpURLConnection (and other kinds of connections) rather than
being more like an HttpClient.
We have already written a small class called HttpClient that *does*
resend cookies when a java.net.HttpURLConnection is redirected and it solves
the problem. We, however, would like to see the Ant Get task become a little
more robust and handle this for us so we don't have to worry about including
this HttpClient tool in GlazedLists... a place it doesn't belong.
My question to you is, if we do the work of merging this into the
GetTask and submit a fix, is it a fix that ant devs would accept? Remember,
the tradeoff of the fix is that we'll have to set a boolean on
java.net.HttpURLConnection to tell it NOT to handle redirects, since we will
want to handle them ourselves, manually. It's not tremendously difficult,
but I just want a green light of approval before I invest the time.
Thanks,
James Lemieux
