não-www domínios impedem a hospedagem de conteúdo estático no mesmo domínio, correto?

Question

Falha ao usar o domínio não www canonical?

Adoro a ideia de URLs curtos e limpos, como example.com, em www.example.com, e, certamente, o que for usado deve redirecionar para o outro. No entanto, como pesquisei o assunto ao longo do tempo, cheguei à conclusão de que usar o url não-www como url canônico é uma desvantagem se chegar a hora de hospedar conteúdo estático em um domínio separado sem aumentar o tamanho da transferência com cookies.

O domínio não www compartilha cookies com todos os subdomínios

Em outras palavras, se o link for seu URL canônico, é muito provável que ele inclua cookies. Devido à maneira como os cookies são definidos, esses cookies serão compartilhados com todos os subdomínios, como users.example.com, dev.example.com, www.example.com e, o mais importante, images.example.com ou arquivos.example .com.

Assim, se você deseja veicular conteúdo de arquivo estático de um subdomínio separado, acabará agrupando cookies do site principal com eles e aumentando o tamanho de transferência da solicitação http.

Nesse caso, para impedir a transmissão de cookies com o conteúdo estático, você precisa comprar um URL completamente separado (por exemplo, examplefiles.com).

o domínio www mantém os cookies compartimentados

Por outro lado, se você definir www.example.com como o URL canônico, acredito que o cookie se aplique somente a esse URL. site, e não para qualquer outro subdomínio. Nesse caso, você economiza a necessidade de comprar e manter uma segunda URL para evitar a exibição de cookies com seu conteúdo estático. Você só precisa verificar se files.example.com ou images.example.com ou algo semelhante está configurado para - não- servir cookies.

Quaisquer fatores atenuantes?

Esta análise está correta? Esse problema não faz uso de uma URL curta, que não seja www, como seu URL canônico um pouco à prova do futuro, neste caminho pequeno, mas potencialmente importante? Há outros fatores atenuantes que estão faltando, como um método para garantir que o cookie seja definido apenas para o URL curto não-canônico www?

    

Answer 1

Eu não vejo isso como um problema, já que os cookies não são tão grandes e o servidor não precisa enviá-los de volta na resposta. Assim, enquanto sim, um ou mais cookies definidos por example.com "enviarão um balão" para o pedido static.example.com, static.example.com não terá que enviá-lo de volta na resposta, para que a resposta do servidor não seja afetada .

Além disso, se você tem conteúdo que você sabe que é estático (imagens, CSS, JS, etc.), você deve configurar cabeçalhos de controle de cache apropriados, especialmente um cabeçalho Expires no futuro (por exemplo, +1 dia, +1 semana, +50 anos, o que fizer sentido para a frequência com que o conteúdo estático é alterado). Com isso concluído, esses cookies serão enviados apenas uma vez e, em seguida, a necessidade futura desses arquivos será tratada pelo cache do navegador.

Se você ainda acha que isso é demais (eu realmente não consigo ver como isso poderia ser, honestamente), você pode possivelmente atenuá-lo usando caminhos. Por exemplo, se o seu aplicativo da web precisar apenas de cookies em example.com/app, defina o caminho do cookie como / app e, em seguida, os pedidos para static.example.com/images/some-awesome-image.jpg não serão enviados esse cookie porque o caminho não corresponde.

Você pode reduzi-lo ainda mais reduzindo o número de cookies que você usa - para a maioria dos propósitos, um (e apenas um) cookie armazenando um único ID de sessão adiciona apenas alguns bytes (menos de 1 KB em cada implementação que vi / used), e fornece ao servidor uma ampla informação para procurar tudo o que precisa saber sobre o lado do servidor cliente.

Honestamente, se você estiver preocupado com domínios de URLs curtos que tornam seu site não à prova de futuro devido a cookies, acho que você tem um problema arquitetônico com cookies demais / grandes demais e deve reavaliar seu estratégia a partir desse ponto de vista.

    

Answer 2

Sim, sua análise está correta. É claro, você sempre pode baixar uns 10 dólares / ano em um domínio separado e usar qualquer nome de domínio canônico que quiser usar.