[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unidata Support: 20020822: netcdf2All -- HTTPClient package



Roy Britten wrote:


Hi John,

Thanks for your reply.

On Mon, 26 Aug 2002, John Caron wrote:



its extemely simple: instead of a RandomAccessFile, the library
opens a HTTPRandomAccessFile. this uses the HTTP "Range" command to
get ranges of bytes from the remote file. everything else is exactly
the same, and no optimizations like caching are done, although i
think buffering is done.



From what I can see in the ucar.netcdf & ucar.nc2 packages, this is the
only point of entry into the HTTPClient package. 


yes

Is there some

fundamental reason why this package is used, in place of the
functionality in java.net?
The HTTPRandomAccessFile was contributed (by Donald Denbo), and i think he used HTTPClient library simply because it got the job done. I have wanted to rewrite it in order to reduce the footprint, but am not that familiar with HTTP. 


Would I be correct in assuming that a
re-written HTTPRandomAccessFile.java, using java.net.URLConnections
rather than HTTPClient.HTTPConnections, would remove all dependence on
the HTTPClient package? This would allow us to initiate HTTPS
connections.
It sounds likely now that i rethink it. my previous comment about having to read in entire file seems wrong now, as long as you can do the range command in HTTPClient.HTTPConnections.
it seems like you have a clear idea on how it could be done. if you are willing to implement it, i would be happy to assist in any way i can, including testing. it would be great to roll your contribution into the release so others could use it. in particular, HTTPS would be very useful. are there are other features you know of that we would get through this? in your use of java.net, would we need any specific version of JRE? 






obvious guess is a problem with Tomcat range command, but it may be
some minor thing (or an error we arent catching) that is unrelated.



There was reportedly a bug in the handling of the Range header in that
version of Tomcat. I've installed a later release and it appears to
respond correctly. Thanks for the pointer.



great. what version of tomcat had the problem?