I just checked and indeed hackage-server is ignoring the If-none-match header. I'll see if I can make it work.
On Tue, Jun 10, 2014 at 11:38 AM, Duncan Coutts < duncan.cou...@googlemail.com> wrote: > I'm pretty sure it's the hackage-server. I think we simply don't have > code yet to react to the if-none-match. Happstack has some util for > the time-based conditionals, but not the etag one. So it should just > be a matter of us adding a combinator that both serves the etag and > reacts to the if-none-match header. Then we'd go and use that in all > the places where we currently serve etags. At the same time, it's > probably worth making that caching combinator also take an optional > timestamp and "valid for" time, so we can do all our caching things in > one call in each resource handler. > > On 10 June 2014 08:54, Johan Tibell <johan.tib...@gmail.com> wrote: > > We need to figure out if nginx or the hackage-server is to blame here. > > > > > > On Tue, Jun 10, 2014 at 1:34 AM, Gintautas Miliauskas > > <gintautas.miliaus...@gmail.com> wrote: > >> > >> Hi, > >> > >> first of all, a shout out to all ZuriHac2014 folks, thanks for the > gentle > >> introduction to the deeper trenches of Haskell infrastructure! > >> > >> I spent a bit of time looking into why "cabal update" always redownloads > >> the entire package list even though the code has explicit support for > etags, > >> and it looks like etags are broken on the server side. The server does > serve > >> "Etag" headers, but does not react to If-None-Match: > >> > >> $ curl -I --header 'If-None-Match: "1ea6c9a3168b9c186d5bbafd065ce5ec"' > >> hackage.haskell.org/packages/index.tar.gz > >> HTTP/1.1 200 OK > >> Server: nginx/1.6.0 > >> Date: Mon, 09 Jun 2014 23:22:49 GMT > >> Content-Type: application/x-gzip > >> Content-Length: 7193838 > >> Connection: keep-alive > >> Content-MD5: 1ea6c9a3168b9c186d5bbafd065ce5ec > >> ETag: "1ea6c9a3168b9c186d5bbafd065ce5ec" > >> Last-modified: Mon, 09 Jun 2014 23:10:44 GMT > >> > >> In this case the server is supposed to return a 304 code because the > ETag > >> matches, but it returns the usual 200. > >> > >> Here's a well-behaved server for comparison: > >> > >> $ curl -I --header 'If-None-Match: f89ef04efbcb1bbd413c9170523beeb1' > >> http://upload.wikimedia.org/ > >> HTTP/1.1 304 Not Modified > >> Last-Modified: Thu, 03 Oct 2013 22:29:34 GMT > >> Etag: f89ef04efbcb1bbd413c9170523beeb1 > >> X-Timestamp: 1380839374.33426 > >> X-Object-Meta-Mtime: 1366745378.0 > >> Content-Type: text/html > >> X-Varnish: 2552484147 2541352860, 2937266545 2853346814, 523731362 > >> Via: 1.1 varnish, 1.1 varnish, 1.1 varnish > >> Accept-Ranges: bytes > >> Date: Mon, 09 Jun 2014 23:29:36 GMT > >> Age: 38954 > >> Connection: keep-alive > >> X-Cache: cp1064 hit (336), cp3010 hit (1791), cp3007 frontend miss (0) > >> Access-Control-Allow-Origin: * > >> Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, > >> X-Varnish > >> > >> Note the 304 return code. > >> > >> I do not know about the configuration in use on the server, but > something > >> seems to be wrong there. There are some nginx bug reports [1] about > similar > >> issues, not sure if they are relevant here. > >> > >> [1] https://github.com/rgrove/rawgit/issues/13 > >> > >> Best regards, > >> -- > >> Gintautas Miliauskas > >> > >> _______________________________________________ > >> cabal-devel mailing list > >> cabal-devel@haskell.org > >> http://www.haskell.org/mailman/listinfo/cabal-devel > >> > > > > > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel@haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > > -- Gintautas Miliauskas
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
