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

Debbugs page

C
C
Chris Marusich wrote on 12 Dec 2018 22: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 14: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 14:38
control message for bug #33721
(address . control@debbugs.gnu.org)
87k1k7zsm0.fsf@gnu.org
tags 33721 fixed
close 33721
?
Your comment

This issue is archived.

To comment on this conversation send an email to 33721@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 33721
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch