Bug #2990
Mercury MN implementations use redirect for servicing MN.get
100%
Description
Using a redirect to return content is incorrect functionality according to the API spec and client tools may not operate as expected.
The response status for MN.get should be 200 with the message body being the object bytes.
example:
curl -v "http://mercury.ornl.gov/clearinghouse/mn/v1/object/nrdata.nps.gov_gos_2166812.xml"
* About to connect() to mercury.ornl.gov port 80 (#0)
* Trying 160.91.19.43... connected
* Connected to mercury.ornl.gov (160.91.19.43) port 80 (#0)
GET /clearinghouse/mn/v1/object/nrdata.nps.gov_gos_2166812.xml HTTP/1.1
User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
Host: mercury.ornl.gov
Accept: /< HTTP/1.1 307 Temporary Redirect
< Date: Wed, 20 Jun 2012 14:49:55 GMT
< Server: Apache
< Accept-Ranges: bytes
< Location: http://mercury.ornl.gov/metadata/nbii/xml/nps/nrdata.nps.gov_gos_2166812.xml
< Content-Length: 0
< Content-Type: application/xml
<
* Connection #0 to host mercury.ornl.gov left intact
* Closing connection #0
Subtasks
History
#1 Updated by Dave Vieglais almost 12 years ago
Need to verify that this will be a problem for the client tools and systems (e.g. synchronization and replication) before addressing it.
#2 Updated by Dave Vieglais almost 12 years ago
- Target version changed from Sprint-2012.25-Block.4.1 to Sprint-2012.33-Block.5.1
- Milestone changed from CCI-1.0.0 to CCI-1.1
Verified that this doesn't seem to affect synchronization. Leaving ticket open until we are able to verify that there's no problem for client tools and replication.
#3 Updated by Dave Vieglais almost 12 years ago
- Milestone changed from CCI-1.1 to CCI-1.0.2
- Category changed from d1_mercury to mn.Mercury
- Assignee changed from Jim Green to Giri Palanisamy
This is an issue that needs to be resolved for the USGS MN implementation.
The options are:
implement a simple proxy that will handle requests for content. Basically the MN.get endpoint will open a buffered http connection to USGS, and as content is received, pass it on to the client.
Install the MN software stack at Denver where local acces to the content is available.
After discussion with Giri and Ranjeet, option 1 appears to be the only viable choice.
#4 Updated by Dave Vieglais almost 12 years ago
- Status changed from New to Closed
This appears to have been fixed.
