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

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

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: Unidata Support: 20020822: netcdf2All -- HTTPClient package
  • Date: Mon, 26 Aug 2002 16:57:58 -0700 (PDT)
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