NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On 5/13/2012 1:16 AM, Ethan Davis wrote:
Hi Patrick, What is the version of the TDS with which you are trying to synch? The TDS has supported lastModified for quite some time, so it would have to be a pretty old version to not support it. But that's the first thing that comes to mind. You could also try looking at the HTTP "Last-Modified" response headers you are getting back. You can do this with the wget "--save-headers" option. Or, in Firefox, by using a plugin like Live HTTP Headers. John, any chance the file caching in the TDS could be masking a change to the last modified timestamp?
Last-Modified works correctly.We set Content-Length correctly, but Tomcat removes it when it compresses, since its wrong. I assume thats the problem. The headers of a typical request look like:
Request Headers = Accept-Encoding: gzip,deflate User-Agent: ToolsUI v4.3 Host: localhost:8080 Status = 200 HTTP/1.1 200 OK Status Line = HTTP/1.1 200 OK Response Headers = Server: Apache-Coyote/1.1 Last-Modified: Fri, 30 Oct 2009 06:00:00 GMT Accept-Ranges: bytes Content-Type: application/octet-stream Transfer-Encoding: chunked Content-Encoding: gzip Vary: Accept-Encoding Date: Sat, 12 May 2012 20:52:12 GMTI realize as I look at this that if wget doesnt do an Accept-Encoding: gzip,deflate then compression is turned off, and the content-length should work. Can someone capture the request and see what the headers are?
John
thredds archives: