Os cabeçalhos HTTP são configurados pelo CDN ou pelo aplicativo?

Os cabeçalhos HTTP são configurados pelo CDN ou pelo aplicativo?

Esta é uma questão teórica e acho que pode ser muito ampla ou pouco clara.

Foobar é um aplicativo que atende usuários na Internet. Ele depende de um CDN para melhorar sua resiliência, velocidade, etc., para atender as pessoas onde quer que estejam.

  • Os cabeçalhos HTTP (recebidos pelo cliente) são definidos pelo CDN ou pelo aplicativo Foobar (o que implica que o CDN os encaminhará)?

  • Se ambos forem possíveis, quais são os prós e os contras de ambos?

Responder1

Não existe uma resposta universal. O que é feito com/para cabeçalhos depende da solicitação, do CDN específico, do cabeçalho específico e da configuração do seu site (que inclui os cabeçalhos que seu servidor back-end/origem inclui na resposta e como você configura seu site no CDN).

Suponha que, por padrão, a maioria dosos cabeçalhos serão removidosda resposta gerada por um servidor back-end/origem e apenas um (mínimo)subconjunto de cabeçalhos será definidona resposta enviada pelo CDN.

Alguns cabeçalhos (específicos do CDN)poderseradicionadopelo CDN de acordo com suas políticas ou por padrão. Por exemplo, adiciona rapidamente umx-served-by:cabeçalho por padrão e o CloudFront permite que você defina e opcional Server-Timing:cabeçalhopara facilitar a depuração de operações de CDN.

Alguns cabeçalhospoderserpreservadodo seu servidor back-end. Por exemplo, os cabeçalhos Cache-control:e Expires:são bastante comuns. Veja por exemplo:Documentos do Cloud Front

Algunspoderserajustadopelo CDN de maneiras específicas. Por exemplo, veja como Fastly lida com umDate:cabeçalhodefinido na origem.


Razões para definir cabeçalhos no CDN

Em vez de permitir que cada aplicativo faça suas próprias tarefas ou não faça nada, você define uma política única para todos os seus sites e aplicativos no nível CDN.

Bons exemplos sãoCORSeHSTSpolíticas.

Você pode optar por definir/adicionar apenas um cabeçalho específico no CDN quando a origem não o fizer, mas usar o valor da origem se estiver definido lá.

etc etc.


Razões para preservar os cabeçalhos definidos na origem

O aplicativo (desenvolvedor) sabe melhor o que o aplicativo precisa.

Substituir a política de cache padrão por um Cache-Control: private, no-storeé um exemplo de livro que vem à mente.

etc etc.

informação relacionada