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.
FYI -- the http standard says that content-length *must* be removed for a compressed response -- Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 Benno On Mon, May 14, 2012 at 9:56 AM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote: > 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 GMT > > I 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 mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/> > -- Dr. M. Benno Blumenthal benno@xxxxxxxxxxxxxxxx International Research Institute for climate and society The Earth Institute at Columbia University Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
thredds archives: