oh, one more thing I remembered, but committing the http tasks into the sandbox has just reminded me: the java.net implementation of http is woefully inadequate and blissfully different from version to version.
I do not, therefore, think use of the standard classes should be encouraged. both Get.java and the new stuff I have just put in the sandbox are weak in that they do use the existing libraries, arent proper HTTP1.1 clients and cant handle digest auth. Ignoring http issues, there is still some validity in supporting URLs in copy, because then you can use alternate url schemas, such as "classpath:/com/mycompany/web-app_2_2.dtd" inside a copy command, which lets you copy from a classpath resource to an output file However, I suspect that Get does that too -I will have to test it and see -and doc it if so. I am still unsure about the value of trying to integrate remote url fetching with copy. It is not the same, because it has so many more ways of going wrong, different notions of success (should you copy the message that comes back with any error code? What is your code going to do if actual content length < Content-Length?), and the authentication stuff. Especially since the java.net stuff does need replacement for a remote fetch to work properly in all conditions. Trust me on that item :-) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
