NixOS/nixos-channel-scripts

ISOs are redirecting using a 301, should be 302

adisbladis opened this issue · 10 comments

adisbladis commented

See the ISO links at https://nixos.org/download.html

Steps to reproduce:
curl -v https://channels.nixos.org/nixos-20.03/latest-nixos-plasma5-x86_64-linux.iso
Pointing to
https://releases.nixos.org/nixos/20.03/nixos-20.03.3087.b4db68ff563/nixos-plasma5-20.03.3087.b4db68ff563-x86_64-linux.iso using a 301.

Expected:
Should use a 302.

garbas commented

I checked and there is no way to do 302 redirect using x-amz-website-redirect-location header.

We would have to use the Redirect Rules, which we should probably use in the beginning. The caveat is that you can only have up to 50 redirect rules. https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html#configure-bucket-as-website-routing-rule-syntax

adisbladis commented

This issue is basically the same as NixOS/nixos-homepage#345.

The more "dangerous" URL to consider here is curl -v https://channels.nixos.org/nixos-unstable/latest-nixos-plasma5-x86_64-linux.iso where a browser might cache the redirect forever, and therefore re-downloading really old ISOs.

garbas commented

Looking at this again. we can not solve this with Routing Rules, but it could be done with a simple Lamda@Edge function. This would also simplify the channel mirror script.

srhb commented

We just had a sighting in #nixos where the iso and sha (apparently) did not point to the same builds for the user, presumably because of the 301 and having visited one or the other previously.

zimbatm commented

The cache is now served by Fastly so we might be able to resolve that.

My first thought is that we disable the S3 website and instead inspect the response header using Fastly VCL, and build our own 302 redirect based on that.

Profpatsch commented

I ran into this as well:

> curl -I https://channels.nixos.org/nixos-unstable/git-revision
HTTP/2 301 
location: https://releases.nixos.org/nixos/unstable/nixos-21.11pre332033.715f6341195/git-revision

This 301 redirect is clearly wrong and will make browsers cache the rev indefinitely!

delroth commented

Suggested fix: use Fastly VCL on channels.nixos.org to:

  • Change all 301s to 302s (making them not cacheable by clients).
  • Disable caching of the redirect response at the Fastly level.

The motivation behind the latter might not be obvious: I think that it's the easiest way to ensure that a .iso and its checksum always point to the same version. With caching involved, we're ~always going to end up in situations where the TTL of a .iso redirect doesn't match the TTL of the checksum redirect, and this will cause issues. We could in theory modify the channel scripts to call to Fastly to trigger an explicit cache invalidation. I don't think this is much better than just not caching the (cheap, small) redirects in the first place.

  • 👍3
delroth commented

Fixed in NixOS/infra@12c180a and deployed.

  • ❤️2