jwhitlock
commented
7 years ago We can base it off of:
Possibly relevant CloudFront docs:
- Values that you specify when you create or update a web distribution - settings we can set
- Viewer Protocol Policy - Redirect HTTP to HTTPS
- Allowed HTTP Methods - GET, HEAD, OPTIONS
- Forward Cookies - I think we can not forward cookies. Will need to double-check the Kuma endpoints
- Query String Forwarding and Caching - I think we can pick None
- Error Caching Minimum TTL - Something low like content, like 300 seconds.
- Specifying how long objects stay in a CloudFront Edge Cache - It looks like w want to set
max-age=Xin theCache-Controlheaders, and CF Minimum TTL to 0 seconds, to control from the app.- Requirements and Recommendations for using Amazon EC2 and other custom origins - Good tips. The k8s-provided node image does not include NTP.
- Request and response behavior for custom origins - The details, such as handling of specific HTTP headers
- Persistent Connections - CF attempts to maintain a persistent connection, which may have an impact on the number of workers needed behind CF.
- How CloudFront processes responses from your custom origin - Useful details
- How CloudFront processes HTPP 3xx status codes from your origin - caches redirects, controlled by settings and headers
- How CloudFront processes and caches HTTP 4xx status codes from your origin - caching, but more complicated. It is unclear if CF will return our custom 404 page, unless we add it as a standalone page.
- Requiring HTTPS for communication between viewers and CloudFront - Settings plus set the SSL certs.
- Requiring HTTPS for communication between CloudFront and Your Custom Origin - I'm OK w/ HTTP, but existing CDN uses SSL, so why not.
- Using alternate domain names and HTTPS - Extra steps are needed for a domain name that isn't a subdomain of
cloudfront.net
bookshelfdave
escattone
The attachments domain (currently mdn.mozillademos.org) serves four types of requests:
/fileslike files/12984/web-font-example.png, which are user attachments. It is possible to replace a user attachment with a new file, and we can cache on the modification date.@apifiles like @api/deki/files/3613/=hut.jpg, which redirect to a/filesendpoint. These could be cached for a long time.$sampleslike /en-US/docs/Learn/CSS/Styling_text/Fundamentals$samples/Color, which are extracted from user-written wiki content. The content changes when the page is updated.These are good candidates for a CDN. Unlike the static assets, we would want short cache times, so that if a file is removed or updated, it will take effect quickly. We could also use the CloudFront Invalidation API.
Cache headers for
/fileswere improved in #578.NOTE: notes above by @jwhitlock, my name shows as I converted it from a project card to an issue.