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

[THREDDS #HPI-566023]: Error from TDS for escaped characters in request

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: [THREDDS #HPI-566023]: Error from TDS for escaped characters in request
  • Date: Wed, 29 Aug 2007 14:25:24 -0600
Hi Dan,

> We have a TDS installed at: http://satdat1.po.gso.uri.edu/thredds/
> dodsC/ and it looks like it's maybe a little old but before I upgrade
> I'll ask this question.

What version of the TDS are your running?

> When accessed by a current OPeNDAP client I'm getting an error
> returned because it appears the DAP client is escaping certain
> characters in the constraint.  If I try the same request from a
> browser without the escaped constraint it works fine.  Sooo, my
> question is do you think this problem is resolved in a newer version
> of the TDS, or for that matter is it a TDS problem?
> 
> Here is a sample URL that works in a browser:
> 
> http://satdat1.gso.uri.edu/thredds/dodsC/NWAtlanticDec_1km.asc?lat
> [0:2:6]
> 
> and here's what is returned:
> -----
> Dataset {
> Float64 lat[lat = 4];
> } NWAtlanticDec_1km;
> ---------------------------------------------
> lat[4]
> 71.17219543457031, 71.15059661865234, 71.12899780273438,
> 71.1073989868164
> -----
> 
> and here's how it would look with an escaped constraint:
> 
> http://satdat1.gso.uri.edu/thredds/dodsC/NWAtlanticDec_1km.asc?lat%
> 5b0%3a2%3a6%5d
> 
> and here's what is returned:
> -----
> Error {
> code = 2;
> message = "The variable `lat%5b0%3a2%3a6%5d' was not found in
> the dataset.";
> };
> -----

I'm not seeing this problem on our main server 
(http://motherlode.ucar.edu:8080/thredds/) which is at Version 3.16.15 Build 
Date = 2007-08-10 00:32:05

I tried it for both a DDS and ascii response (in case it was the ascii part 
that didn't unencode).

I remember this being a problem but I don't know when it was fixed or whether 
it was in the TDS or OPeNDAP code. Could have been either though I suspect the 
TDS is/should be doing the unencoding.

Ethan


Ticket Details
===================
Ticket ID: HPI-566023
Department: Support THREDDS
Priority: Normal
Status: Open