Со следующим заголовком ответа:
HTTP/1.0 200 OK
Content-Type: video/mp4
Content-Length: 3294545
Connection: keep-alive
Date: Thu, 30 May 2013 21:17:34 GMT
x-amz-meta-s3cmd-attrs: uid:501/gname:staff/uname:americanyak/gid:20/mode:33
152/mtime:1368215923/atime:1369948577/ctime:1
369948245
Cache-Control: no-transform,public,max-age=31536000,s-maxage=31536000
Expires: Fri, 30 May 2014 00:00:00 GMT
Last-Modified: Thu, 30 May 2013 21:16:39 GMT
ETag: "b524b3f434581a1c2daff863cf201540"
Accept-Ranges: bytes
Server: AmazonS3
Age: 1309
Via: 1.0 33c069541cbb3f6e68de8056c044d86e.cloudfront.net (CloudFront)
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: oeZ3EzRFAZggWpgqIbObtJH_MdyrGLMsdxUU3amupI5rkq7sbXPt4A==
Что мне не хватает? Почему это не кеширование?
https://forums.aws.amazon.com/thread.jspa?threadID=124998
Привет,
Хотя нам известно о проблеме с ответами HTTP / 1.0 206 на запрос диапазона и Chrome, мы не можем предоставить ETA для исправления. Поскольку эта проблема специфична для запросов диапазона, немедленным решением будет отключить запросы диапазона на исходном сервере, если это возможно для вашего варианта использования.
Также стоит упомянуть, что несколько поставщиков приложений для веб-прокси и кеширования используют HTTP / 1.0 в качестве стандарта де-факто в течение многих лет, поэтому вы, вероятно, время от времени будете получать аналогичные отчеты от своих конечных пользователей, использующих Chrome, но не других браузеров, таких как Firefox или Сафари. Например, вот обсуждение подобного отчета между разработчиком Chrome в списке рассылки популярного веб-кеша Squid: http://www.squid-cache.org/mail-archive/squid-dev/201204/0113.html Я не говорю, что всегда возвращаемый HTTP / 1.0 останется навсегда, но сегодня это довольно распространено в реальных ситуациях.
Мы работаем над исправлением на будущее.
С Уважением,
Мэтт Дж.
На тот момент у меня были аналогичные проблемы с текущей версией Chrome. Основная проблема заключалась в том, что Chrome не кэшировал видео, размещенное на s3 и обслуживаемое Cloudfront. Я объясняю, мы используем собственный видеоплеер HTML5, в котором мы используем функции автозапуска и цикла. После того, как видео закончится, Chrome запросит видео у Cloudfront вместо того, чтобы извлекать его из кеша на диске.
Мы заметили две вещи: этой проблемы не было в Firefox. И некоторые веб-сайты, которые размещают свои видео на своих VPS, не испытывают той же проблемы, когда мы используем Chrome.
Мы полагаем, что проблема возникает, когда хром запрашивает частичные данные для потоковой передачи видео (статус 206) из Cloudfront, и кажется, что он не знает, что видео было полностью загружено.
На данный момент мы не смогли найти решения ...
Мне удалось обойти проблему, отключив ETag заголовок на моем исходном сервере.
CloudFront не любит ETag ссылки почему-то.
По сей день запросы, отправленные с Range заголовок для video/mp4 файлы через CloudFront приводят к возврату всего объекта с 200 OK вместо того 206 Partial Content когда клиент отправляет If-Range заголовок с кешированным ETag ссылка.
Удаление ETag заголовок с исходного сервера эффективно решает проблему, поскольку клиент больше не будет отправлять If-Range, и CloudFront вернется 206 Partial Content как и ожидалось.
Кроме того, это предотвратит промахи кеша (X-Cache: Miss from cloudfront), экономя пропускную способность и ускоряя запросы CDN.
Вот как это можно сделать с помощью Express 4 для статических файлов:
// Allow access to site folder
app.use( express.static('./site', { etag: false } ) );