Usando o Redirect para um SSL CDN para ter um domínio personalizado

Question

Estamos tentando transferir nossos recursos de website / app para um CDN. O problema é que nosso CDN não oferece nomes de domínio personalizados com SSL. Em outras palavras, para o SSL, eles oferecem https://1234.cdn.hostingcompany.com , mas não https://assets.mysite.com .

Então, isso parece ser um grande problema, pois não quero publicar novamente meu aplicativo com o domínio codificado.

Por isso, li em algum lugar sobre um método em que você envia pessoas para https://assets.mysite.com e, em seguida, redireciona para https://1234.cdn.hostingcompany.com .

Existe mérito para essa solução ou isso iria derrotar completamente o propósito do CDN.

    

Answer 1

Você pode configurar seu próprio servidor no link (com um certificado SSL válido para esse SN), que retorna um Redirecionamento 301 para link . Isso funcionará para qualquer coisa que o navegador carregue. Se seu webapp tiver JavaScript ou qualquer outra coisa (Flash, Silverlight, etc), o deve ainda funcionar, mas você deve testar bastante.

A grande desvantagem disso é que todos os pedidos de conteúdo de CDN atingirão seu servidor primeiro. A transferência de dados será mínima, mas o atraso será no mínimo de centenas de milissegundos. Depois de terem sido redirecionados uma vez, o navegador deve lembrar o redirecionamento e acessar a URL real da CDN sem precisar de um bug no servidor no futuro (o cache do navegador limitará esse efeito).

Se você está descarregando conteúdo porque é um hacker de dados, essa ainda é uma maneira decente de realizar o que você deseja. Se você estiver descarregando conteúdo para melhorar os tempos de resposta, isso não atingirá esse objetivo.

Como Ceejayoz apontou, você poderia transformar a URL do CDN em uma variável de configuração para o seu aplicativo. URLs de codificação rígida é uma maneira rápida de manter um código espaguete inatingível que todo mundo odeia.

    

Answer 2

Eu acredito que ele terá um impacto não trivial, pelas seguintes razões:

• Aperto de mão SSL: a primeira conexão com https://assets.mysite.com será cara, exigindo muitas viagens de ida e volta TCP. Após essa primeira conexão, supondo que outros recursos sejam solicitados com relativa rapidez, o cliente pode reutilizar a conexão ou, pelo menos, reutilizar a sessão SSL, em vez de fazer um handshake completamente novo.
• cada recurso novo e diferente exigirá um hit para assets.mysite.com primeiro, antes de obter um redirecionamento para o CDN. Se você tem um conjunto pequeno e fixo de ativos, isso pode ser aceitável.
• dependendo da implementação do cliente, até mesmo um 301 não pode ser armazenado em cache muito bem. [precisa de verificação]
• você mencionou o aplicativo para dispositivos móveis?

Aplica-se uma renúncia habitual de "medida, medida, medida".