Qual é o objetivo de (Apache) colocar inode em um ETAG?

Question

Existem muitos artigos na web detalhando por que você pode não Deseja usar o formato inode-m-size padrão do Apache para ETAGS.

Mas ainda não li nada sobre o que poderia ter motivado a inclusão de inode para o Apache em primeiro lugar. Em face disso, só parece útil se é necessário diferenciar entre fac-símiles de octeto por octeto do mesmo recurso, mas isso certamente é contrariado com o próprio objetivo das etags.

Os autores da Apache não são conhecidos por sua entrega desleixada nos padrões da Internet, então sinto que devo estar perdendo alguma coisa. Alguém pode elaborar?

EDITAR: Pergunto isso aqui e não no Serverfault.com porque estou implementando um servidor da web em vez de administrar um. Para ler mais sobre por que é uma má ideia, veja por exemplo aqui ou aqui. Todos esses artigos recomendam a mesma coisa: remova os inodos de seus ETAGs. A questão é: existe alguma vantagem para eles estarem lá?

Answer 1

Parece que o tipo de coisa que se poderia facilmente fazer por um palpite errado pelo que é o caso comum ou preferindo a correção ao desempenho, por padrão, sempre que houver um pingo de dúvida.

Permita -me inventar uma história sobre como pode ter ido:

Eles decidem cedo que uma soma de hash/verificação sobre o conteúdo é uma má idéia por razões de desempenho. "Quem sabe o tamanho do arquivo? Não podemos recalculá -los o tempo todo ..." Então eles decidem o tamanho e a data o deixam bem perto.

"Mas espere", diz a pessoa A, "nada garante que você não tenha uma colisão de tamanho de arquivo. Na verdade, existem casos, como binários de firmware, quando o tamanho do arquivo é sempre o mesmo, e é inteiramente possível que vários sejam Carregado de uma máquina de dev ao mesmo tempo, portanto, não são suficientes para distinguir entre diferentes conteúdos ".

Pessoa B: "Hmm, bom ponto. Precisamos de algo intrinsecamente ligado ao conteúdo do arquivo. Algo que, juntamente com o tempo modificado, pode dizer com certeza se é o mesmo conteúdo".

Pessoa A: "E o inode? Agora, mesmo que renomeie os arquivos (talvez eles mudem" recomendados "para um arquivo diferente, por exemplo), o ETAG padrão funcionará bem!"

Pessoa B: "Não sei, o inode parece um pouco perigoso".

Pessoa A: "Bem, o que seria melhor?"

Pessoa B: "Sim, boa pergunta. Acho que não consigo pensar no que especificamente está errado com isso, apenas tenho um sentimento ruim geral sobre isso".

Pessoa A: "Mas pelo menos garante que você baixe um novo, se mudou. O pior que acontece é que você baixará com mais frequência do que precisa, e qualquer pessoa que saiba que não precisa se preocupar com isso pode apenas girar isso fora. "

Pessoa B: "Sim, isso faz sentido. Provavelmente é bom para a maioria dos casos, e parece melhor do que as alternativas fáceis".

Isenção de responsabilidade: não tenho conhecimento interno sobre o que os implementadores do Apache poderiam estar pensando. Tudo isso é apenas uma adivinhação de ondência manual e tentando fazer uma história plausível. Mas eu certamente vi esse tipo de coisa acontecer com frequência.

Você nunca sabe o que não pensou (neste caso, que servidores redundantes balanceados de carga que servem os mesmos arquivos eram mais típicos do que ter que se preocupar com o tamanho+colisões de tempo). O balanceador de carga não faz parte do Apache, o que facilita a supervisão.

Além disso, o modo de falha aqui é que você não fez uso perfeitamente eficiente do cache (não que você tenha dados errados), o que é sem dúvida melhor, embora irritante. O que sugere que, mesmo que pensassem, eles poderiam razoavelmente assumir que alguém com interesse suficiente para configurar um balanceador de carga também estaria bem em ajustar seus detalhes de configuração.

PS: Não se trata de padrões. Nada especifica como você deve calcular o ETAG, apenas que deve ser suficiente para saber se o conteúdo mudou, com alta probabilidade.