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

DoneSubmitted by Chris Marusich.
Details
2 participants
  • Chris Marusich
  • Ludovic Courtès
Owner
unassigned
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 addressas berlin.guixsd.org) does not return a Cache-Control header for somesubstitutes. I've tried various URLs under the /nar/gzip/ prefix, andand they all omitted a Cache-Control header in the response. Forexample:
Toggle snippet (9 lines)$ curl --dump-header - -s -o /dev/null https://ci.guix.info/nar/gzip/0fw7w396llw316nj36dsqnbkxzc9bqwa-python-itsdangerous-0.24HTTP/1.1 200 OKServer: nginx/1.14.1Date: Thu, 13 Dec 2018 06:49:04 GMTContent-Type: application/octet-stream;charset=ISO-8859-1Content-Length: 19449Connection: 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.narinfoHTTP/1.1 200 OKServer: nginx/1.14.1Date: Thu, 13 Dec 2018 06:49:25 GMTContent-Type: application/x-nix-narinfo;charset=utf-8Content-Length: 1456Connection: keep-aliveCache-Control: max-age=7776000
I expected all URLs to return an appropriate Cache-Control header (atleast when returning an HTTP 200 response), especially the URLs for thegzipped substitutes themselves, since they are likely to be large. Isthere a reason why we do not include a Cache-Control header for allsubstitutes under the /nar/gzip/ prefix?
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwSAxwACgkQ3UCaFdgiRp0hnRAAlbfMaogCHXKrs2nlvsi5b+AbYmrChimKpuEnan64YO6YHBGDpuU+Dh2FOKcg9lMAGaYqnKcb8YQsU3aQuIntwIaHBPxkpEiwYklGCeaBYwoKoKtLAXdLLvmDjgU2Nnf8lxVuP3WTwK5H1aWROveQfUZqsPUL0Pq+G5jGAUnUEKPPePsC44A7nGilARlvaO2liXLkJHBH3ceq/fqMLaD6dmbxdDsmYB/efNdYQxUCtS9zYwuFhDXIh2/koiARkH/Ah93DWjH2n6Q0vMqhGkaXdlnbcML1jF0MmKmtUV5WJqnunrV6T0nKLo4Oor6x8QptwEQ/fU/xMMZv1hWv6kPtj7ZCvPQ5CG0Ucf6IerkhLDwCQK/lsOSE8UBfXzrgZt4D/KDNCQ2NHeYwXk4fhKJsynTK/1fZj1lnh6dGImGvEVRmLdwVp/1tMEg5u+UJrkJ1AMcaZdVEjwvueb4dCoeW01TW0y0W3pI4mthDMZcINiSnZSWOQYKEjYaOjHNGYwrpysrdLeZ7cG8fw9K1HIq6q9Morvr/v5iWeFym37pte072fGFl3UZ4PIBUbAO/ncz9XaOGY4AF1SYwc0Qf9eTJdN22qRiU0TZZ09mXhMig3WC3jwaiKc3zrSmkATMsm174BVXwSgsUFvstlGZmLZuX/++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 onnarinfo responses. The idea was that nars themselves can be cachedforever. 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 fixedclose 33721
?
Your comment

This issue is archived.

To comment on this conversation send email to 33721@debbugs.gnu.org