Atraso específico do Amazon CloudFront CORS

Question

Estou com um atraso entre a exibição de solicitações de CORS, mas as solicitações diretas são atendidas bem. Estou usando isso para distribuir fluxos de mídia via HTTP, por isso é muito importante reduzir o atraso de inicialização.

Há aproximadamente 90-180 segundos entre o momento em que um manifesto de mídia está disponível por meio da distribuição do CloudFront (por solicitação direta do navegador ou curl) e quando as solicitações de CORS do player em nosso site retornam sucesso. Eu habilitei o encaminhamento de solicitações OPTIONS na distribuição do CloudFront e incluí os resultados de uma solicitação OPTIONS também. Incluí o resultado de uma solicitação de onda e o resultado correspondente da guia de rede das ferramentas do Chrome Dev abaixo. Observe que essas solicitações foram feitas do mesmo cliente em 15 segundos uma da outra (a solicitação de curl foi enviada primeiro).

=== Solicitação de CURL ===

*   Trying 54.192.135.101...
* Connected to <exampleDistributionID>.cloudfront.net (1.1.1.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*    subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.cloudfront.net
*    start date: Sep 17 00:00:00 2015 GMT
*    expire date: Dec 15 23:59:59 2016 GMT
*    subjectAltName: <exampleDistributionID>.cloudfront.net matched
*    issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
*    SSL certificate verify ok.
> GET /path/to/manifest/stream.m3u8 HTTP/1.1
> Host: <exampleDistributionID>.cloudfront.net
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/vnd.apple.mpegurl
< Content-Length: 1435
< Connection: keep-alive
< Server: nginx/1.9.10
< Date: Sun, 17 Apr 2016 00:26:06 GMT
< Last-Modified: Sun, 17 Apr 2016 00:26:05 GMT
< ETag: "5712d81d-59b"
< Cache-Control: no-cache
< Access-Control-Allow-Origin: *
< Accept-Ranges: bytes
< X-Cache: Miss from cloudfront
< Via: 1.1 f687c6e8ce478528ab87681ac35779ab.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: P01_dDWZRWZ0lzAqROqOMnaipstK484vPWnicw3F0kcG_7elxBGNkQ== 

<...Content of stream.m3u8...>

=== Solicitação do Chrome ===

Captura de tela da guia Rede de ferramentas do Chrome Dev mostrando o erro 404 recebido

=== Pedido de OPÇÕES ===

*   Trying 1.1.1.1...
* Connected to <exampleDistributionID>.cloudfront.net (1.1.1.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*    subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.cloudfront.net
*    start date: Sep 17 00:00:00 2015 GMT
*    expire date: Dec 15 23:59:59 2016 GMT
*    subjectAltName: <exampleDistributionID>.cloudfront.net matched
*    issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
*    SSL certificate verify ok.
> OPTIONS /path/to/manifest/stream.m3u8 HTTP/1.1
> Host: <exampleDistributionID>.cloudfront.net
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Content-Length: 0
< Connection: keep-alive
< Server: nginx/1.9.10
< Date: Sun, 17 Apr 2016 22:05:15 GMT
< Access-Control-Allow-Origin: http://my.origin.com
< Access-Control-Allow-Methods: GET, OPTIONS
< Access-Control-Allow-Headers: Authorization
< Access-Control-Allow-Credentials: true
< X-Cache: Miss from cloudfront
< Via: 1.1 ed2825b48bb51b4febd93a82e71f7ed9.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: WY-KPfTlNTenTjWyYF9GS4ikyrGMQONAm4mXpbuKpHzfBk_xKfxG2w==
< 
* Connection #0 to host <exampleDistributionID>.cloudfront.net left intact

Perda de ver o erro na minha configuração, qualquer ajuda seria muito apreciada.

    

Answer 1

O CloudFront tenta proteger o servidor de origem contra solicitações desnecessárias de objetos indisponíveis, armazenando em cache respostas a erros por 5 minutos, por padrão .

Parecia aparente pela pergunta que a explicação mais provável seria que o objeto estava sendo requisitado (por qualquer motivo) antes que ele realmente existisse, e a resposta de erro estava sendo armazenada em cache por alguns minutos, levando ao que parecia ser um "atraso" na disponibilidade do objeto. Mas o CloudFront não tem atrasos de propagação, porque o CloudFront é um cache pull-through - não há nada para propagar.

Seu teste curl parece ser bem-sucedido, mas não prova nada, aparentemente porque (entre outras razões possíveis) você não incluiu um Origin: no seu pedido curl . Isso torna a solicitação curl semanticamente diferente daquela enviada pelo navegador.

Ao avaliar se um objeto está disponível para ser servido no cache, o CloudFront não considera apenas o caminho. A maioria dos cabeçalhos que são encaminhados para o servidor de origem também são comparados e, se os cabeçalhos a serem encaminhados com essa solicitação não corresponderem aos cabeçalhos enviados com uma solicitação anterior com uma resposta armazenada em cache disponível, a resposta armazenada em cache não será usada e uma solicitação será enviada para a origem. Sua resposta será armazenada em cache junto com os cabeçalhos enviados.

Então, as duas solicitações a seguir:

GET /object HTTP/1.1
Host: www.example.com

e

GET /object HTTP/1.1
Host: www.example.com
Origin: http://www.example.com

... são (supondo que o Origin: header está sendo encaminhado para o servidor de origem, como seria necessário para o CORS) tratado como duas solicitações diferentes, essencialmente não relacionadas, por necessidade - o CloudFront não sabe se o servidor de origem pode modificar suas respostas com base nos cabeçalhos de solicitação enviados. As respostas a essas duas solicitações seriam armazenadas em cache separadamente, e cada uma delas só seria atendida em resposta a solicitações de correspondência futuras.

Se a distribuição estiver configurada para encaminhar cookies ou cadeias de consulta, elas também serão armazenadas junto com a resposta em cache, que será atendida somente em resposta a solicitações que correspondam exatamente à solicitação original que gerou a resposta armazenada em cache - com base em todos os parâmetros encaminhados. (É por isso que o encaminhamento desnecessário de informações que o servidor de origem não precisa afetará a sua taxa de cache.)

Definindo o erro de cache com o TTL mínimo da distribuição para erros 404 até 0 resolve esse problema, impedindo o armazenamento em cache das respostas 404.