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

[netCDF #JVY-917863]: An odd issue...

The following ncdump command also appears to work using the latest
github master for netcdf-c.

ncdump -h 
https://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc

Can anyone indicate what version of the netcdf-c library is producing these
failures?


> Hi Nathan,
> 
> what version of Panoply are you using?
> 
> I could not re-produce the problem you reported on my side.
> 
> For this example,
> 
> https://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc
> 
> See screenshot attached.
> 
> Thanks,
> Sandra
> 
> 
> ---------------------------------------------------------
> Jet Propulsion Laboratory / Physical Oceanography DAAC
> Email: address@hidden
> Website: http://podaac.jpl.nasa.gov
> ---------------------------------------------------------
> 
> Ticket History
> ===================
> Nathan Potter (Client) Posted On: 13 April 2018 02:05 PM
> 
> ===============================================================
> 
> Greetings,
> 
> I have had two support requests in the past 24 hours in which a user was 
> unable to utilize a DAP client to retrieve data from:
> 
> https://podaac-opendap.jpl.nasa.gov/opendap/
> 
> In my tests I could not retrieve data using Panoply, IDV, Tools-UI, or Matlab 
> R2016b
> 
> However, Matlab R2017b and R2018a both work.
> 
> And I think the problem lies in the HTTPS/SSL/TLS stack.
> 
> For example, this dataset:
> 
> https://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc
> 
> Causes Panoply to issue this error message:
> 
> There was an error loading the data:
> Error creating data source:file.grid with: 
> https://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc
> Grid data source failed making data set: 
> https://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc
> handshake alert:  unrecognized_name
> 
> 
> And if I change the the protocol to HTTP:
> 
> http://podaac-opendap.jpl.nasa.gov/opendap/allData/saral/preview/L2/XOGDR-SSHA/c112/SRL_OPRSSHA_2PTS112_0002_20170828_153728_20170828_171708.EUM.nc
> 
> 
> It works fine in Panoply. Which is deeply perplexing as this URL simply 
> returns a 302 redirect to the HTTPS endpoint for the dataset.
> 
> I am wondering if a deployment configuration change at PODAAC could have 
> exposed a bug in the NetCDF code.
> 
> Command line curl works just fine for all of this which might also point to 
> the UNIDATA code simply because, in my experience, curl is pretty intolerant 
> of misconfigured servers…
> 
> Although I am not really in a position to take any action to fix this, I 
> would really appreciate it if I could be kept in the loop for the solution, 
> if one materializes.
> 
> 
> Thanks,
> 
> Nathan
> 
> = = =
> Nathan Potter                        ndp at opendap.org
> OPeNDAP, Inc.                        +1.541.231.3317
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Ticket Details
> ---------------------------------
> Ticket ID: 82994
> Department: PO.DAAC
> Type: Feedback
> Status: Waiting for User
> Priority: Normal
> 
> Helpdesk: https://support.earthdata.nasa.gov/index.php?
> 
> 

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: JVY-917863
Department: Support netCDF
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.