S3 WebsiteRedirectionLocation meta выглядит агрессивно в браузере

Question

Я пытаюсь создать службу перенаправления URL-адресов с помощью S3, и хотя основная часть работы выполнена, я сталкиваюсь с некоторыми крайними случаями, такими как редактирование перенаправлений после их создания. Я AWS Javascript SDK и метод putObject () для создания этих ключей, и у меня есть домен, сопоставленный с корзиной - mybucket.com, и я не нахожусь за Cloudfront.

Если я создаю key, foo и установите для WebsiteRedirectionLocation что-то вроде https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property все работает просто отлично. Посещение https://mybucket.com/foo перенаправляет на https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property.

Однако я допустил ошибку и мне нужно изменить URL, поэтому я захожу в консоль AWS и редактирую метаданные этого ключа, чтобы изменить веб-сайт перенаправление на https://google.com и затем снова посещение https://mybucket.com/foo, но оно все еще перенаправляет на https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property. Однако, если я захожу по URL-адресу в частном браузере, он правильно перенаправляет на Google, который сообщает мне, что перенаправление кэшировано браузером.

Так что, похоже, мой браузер кэширует перенаправление. Теперь я установил следующие атрибуты при создании ключа с помощью метода putObject:

CacheControl: 'no-store',
Expires: 123456789,

Что, вероятно, является избыточным, поскольку CacheControl: no-store должен указывать браузеру, что он никогда не кэширует это право? Я установил для Expires значение 123456789, срок действия которого истек в 1973 году, поэтому я предположил, что браузер просто скажет, что гораздо позже, чем в 1973 году, так что загрузите новую версию. Я также должен отметить, что я добавил атрибут Expires только после настройки CacheControl, не имеющей эффекта.

Весь вызов putObject, который я выполняю, выглядит следующим образом:

  S3.putObject(
    {
      Bucket: BUCKET_NAME,
      Key: 'foo',
      CacheControl: 'no-store',
      Expires: 123456789,
      WebsiteRedirectLocation: 'https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property',
      Metadata: {
        someOtherThing: 'whatever',
      },
    }
  );

Единственное, что я вижу, это то, что заголовки ответа от объекта S3, по-видимому, не имеют атрибутов как cache-control, так и expires:

Content-Length: 0
Date: Tue, 14 Apr 2020 14:29:34 GMT
Location: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#putObject-property
Server: AmazonS3
x-amz-id-2: ldfskg;lksdjfgl;kdfjslgk;jdsflk;gjfsd
x-amz-request-id: ;fdjsglsfdkglfldsjglksf

Answer 1

К сожалению, так работают современные браузеры. Они автоматически кэшируют ответы HTTP 301. Это имеет определенный смысл, поскольку ответ называется Moved Permanently. Вам нужно вернуть HTTP 302, который равен Moved Temporarily

. Это подводит нас к другой проблеме: вы пытаетесь использовать метатег S3 Website-Redirect-Location для возврата ответа 302. К сожалению, нет способа сделать это.

Я нашел обходной путь для выполнения sh этого с помощью S3: вы можете создать правило перенаправления.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>foo</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HttpRedirectCode>302</HttpRedirectCode>
      <HostName>example.com</HostName>
      <Protocol>https</Protocol>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Приведенные выше правила маршрутизации в основном делают так что mybucket.com/foo будет перенаправлять на https://example.com с кодом ответа 302.

Правила маршрутизации являются функцией хостинга веб-сайта S3 stati c, поэтому вы можете просто добавить это в разделе хостинга веб-сайта stati c вашего ведра в AWS консоли. Это не красиво, но должно сработать.