Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: