Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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. Is there some fundamental reason why this package is used, in place of the functionality in java.net? 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. > 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. Thanks, Roy. -- Roy Britten QSS Group, Inc. Computational Sciences Division (Code IC) NASA Ames Research Center Phone: (650) 604-4532 Fax: (650) 604-3594
netcdf-java archives: