ci.guix.info does not return Cache-Control header for substitutes

  • Done
  • quality assurance status badge
Details
2 participants
  • Chris Marusich
  • Ludovic Courtès
Owner
unassigned
Submitted by
Chris Marusich
Severity
normal
C
C
Chris Marusich wrote on 13 Dec 2018 07:58
(address . bug-guix@gnu.org)
87d0q5yktf.fsf@gmail.com
Hi,

I've noticed that ci.guix.info (which I see maps to the same IP address
as berlin.guixsd.org) does not return a Cache-Control header for some
substitutes. I've tried various URLs under the /nar/gzip/ prefix, and
and they all omitted a Cache-Control header in the response. For
example:

Toggle snippet (9 lines)
$ curl --dump-header - -s -o /dev/null https://ci.guix.info/nar/gzip/0fw7w396llw316nj36dsqnbkxzc9bqwa-python-itsdangerous-0.24
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 13 Dec 2018 06:49:04 GMT
Content-Type: application/octet-stream;charset=ISO-8859-1
Content-Length: 19449
Connection: keep-alive

However, some URLs do include a Cache-Control header in the response.
For example:

Toggle snippet (10 lines)
$ curl --dump-header - -s -o /dev/null https://ci.guix.info/s8v7vrzgpjkyf72dlbifhprabqqlx696.narinfo
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Thu, 13 Dec 2018 06:49:25 GMT
Content-Type: application/x-nix-narinfo;charset=utf-8
Content-Length: 1456
Connection: keep-alive
Cache-Control: max-age=7776000

I expected all URLs to return an appropriate Cache-Control header (at
least when returning an HTTP 200 response), especially the URLs for the
gzipped substitutes themselves, since they are likely to be large. Is
there a reason why we do not include a Cache-Control header for all
substitutes under the /nar/gzip/ prefix?

--
Chris
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwSAxwACgkQ3UCaFdgi
Rp0hnRAAlbfMaogCHXKrs2nlvsi5b+AbYmrChimKpuEnan64YO6YHBGDpuU+Dh2F
OKcg9lMAGaYqnKcb8YQsU3aQuIntwIaHBPxkpEiwYklGCeaBYwoKoKtLAXdLLvmD
jgU2Nnf8lxVuP3WTwK5H1aWROveQfUZqsPUL0Pq+G5jGAUnUEKPPePsC44A7nGil
ARlvaO2liXLkJHBH3ceq/fqMLaD6dmbxdDsmYB/efNdYQxUCtS9zYwuFhDXIh2/k
oiARkH/Ah93DWjH2n6Q0vMqhGkaXdlnbcML1jF0MmKmtUV5WJqnunrV6T0nKLo4O
or6x8QptwEQ/fU/xMMZv1hWv6kPtj7ZCvPQ5CG0Ucf6IerkhLDwCQK/lsOSE8UBf
XzrgZt4D/KDNCQ2NHeYwXk4fhKJsynTK/1fZj1lnh6dGImGvEVRmLdwVp/1tMEg5
u+UJrkJ1AMcaZdVEjwvueb4dCoeW01TW0y0W3pI4mthDMZcINiSnZSWOQYKEjYaO
jHNGYwrpysrdLeZ7cG8fw9K1HIq6q9Morvr/v5iWeFym37pte072fGFl3UZ4PIBU
bAO/ncz9XaOGY4AF1SYwc0Qf9eTJdN22qRiU0TZZ09mXhMig3WC3jwaiKc3zrSmk
ATMsm174BVXwSgsUFvstlGZmLZuX/++pZGXnXlWcCPeKXhy7u+E=
=VFW3
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 17 Dec 2018 23:38
(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33721@debbugs.gnu.org)
87lg4nzsm6.fsf@gnu.org
Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (6 lines)
> I've noticed that ci.guix.info (which I see maps to the same IP address
> as berlin.guixsd.org) does not return a Cache-Control header for some
> substitutes. I've tried various URLs under the /nar/gzip/ prefix, and
> and they all omitted a Cache-Control header in the response. For
> example:

Until now ‘guix publish’ would set ‘Cache-Control’ headers only on
narinfo responses. The idea was that nars themselves can be cached
forever. However it probably makes more sense to set the same
‘Cache-Control’ header on nar responses.

Fixed in 9b9de08477afe0ea519f916ad3d33c9720c3278d.

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 17 Dec 2018 23:38
control message for bug #33721
(address . control@debbugs.gnu.org)
87k1k7zsm0.fsf@gnu.org
tags 33721 fixed
close 33721
?