Objects in dist/ are "convenience" objects, i.e. they are a well-known
URL to the latest build in a given repo. Since they're updated on every
build, we can't cache or CDN them properly, but we can generate a
redirect from dist/ to the corresponding object in archive/.
The easiest way to do redirects in S3 is to slap an
x-amz-website-redirect-location metadata header on an object.
Unfortunately, S3 generates a "301 Moved Permanently" response for such
objects and doesn't bother to also send a Cache-Control header, which
makes the redirect cacheable and useless for the purpose of a
frequently-updated pointer.
Fortunately, S3 static website hosting supports bucket-wide redirection
rules, which do allow control over the response code, and so we use
that. There is a limit of 50 redirection rules per bucket, but that's
unlikely to pose a problem, especially since the rules are prefix-based,
so we only need one rule to handle all files belonging to a particular
artifact (the main file, signature, checksum, etc).
Objects in
dist/are "convenience" objects, i.e. they are a well-known URL to the latest build in a given repo. Since they're updated on every build, we can't cache or CDN them properly, but we can generate a redirect fromdist/to the corresponding object inarchive/.The easiest way to do redirects in S3 is to slap an
x-amz-website-redirect-locationmetadata header on an object. Unfortunately, S3 generates a "301 Moved Permanently" response for such objects and doesn't bother to also send aCache-Controlheader, which makes the redirect cacheable and useless for the purpose of a frequently-updated pointer.Fortunately, S3 static website hosting supports bucket-wide redirection rules, which do allow control over the response code, and so we use that. There is a limit of 50 redirection rules per bucket, but that's unlikely to pose a problem, especially since the rules are prefix-based, so we only need one rule to handle all files belonging to a particular artifact (the main file, signature, checksum, etc).