Pregunta

Hay muchos artículos en la web que detallan por qué podrías no desea utilizar el formato inode-mtime-size predeterminado de Apache para ETags.

Pero todavía tengo que leer algo sobre lo que podría haber motivado la inclusión de inodo para Apache en primer lugar.A primera vista, sólo parece útil si es necesario poder diferenciar entre facsímiles octeto por octeto del mismo recurso, pero esto seguramente va en contra del propósito mismo de las ETags.

Los autores de Apache no son conocidos por su manejo descuidado de los estándares de Internet, por lo que siento que me falta algo.¿Alguien puede dar más detalles?

EDITAR: Pregunto esto aquí en lugar de en ServerFault.com porque estoy implementando un servidor web en lugar de administrarlo.Para leer más sobre por qué es una mala idea, consulte, por ejemplo. aquí o aquí.Todos estos artículos recomiendan lo mismo:elimine los inodos de sus etiquetas electrónicas.La pregunta es: ¿hay alguna ventaja en que estén allí?

¿Fue útil?

Solución

Parece el tipo de cosas que uno podría hacer fácilmente con una suposición errónea de cuál es el caso común, o prefiriendo la corrección al rendimiento, por defecto, siempre que haya una pizca de duda.

Permítanme inventar una historia sobre cómo podría haber sido:

Deciden desde el principio que un hash/suma de comprobación del contenido es una mala idea por motivos de rendimiento."¿Quién sabe qué tamaño podría tener el archivo?No podemos recalcularlos todo el tiempo..." Entonces deciden que el tamaño y la fecha te acercan bastante.

"Pero espera", dice la persona A, "nada garantiza que no tengas una colisión en el tamaño del archivo.De hecho, hay casos, como los archivos binarios de firmware, en los que el tamaño del archivo es siempre el mismo y es muy posible que se carguen varios desde una máquina de desarrollo al mismo tiempo, por lo que no son suficientes para distinguir entre diferentes contenidos. "

Persona B:"Mmmm, buen punto.Necesitamos algo que esté intrínsecamente ligado al contenido del archivo.Algo que, junto con la hora modificada, puede decirte con certeza si se trata del mismo contenido".

Persona A:"¿Qué pasa con el inodo?Ahora, incluso si cambian el nombre de los archivos (tal vez cambien "recomendado" a un archivo diferente, por ejemplo), ¡la etiqueta electrónica predeterminada funcionará bien!

Persona B:"No lo sé, el inodo parece un poco peligroso."

Persona A:"Bueno, ¿qué sería mejor?"

Persona B:"Sí, buena pregunta.Supongo que no puedo pensar qué es lo que está mal específicamente, sólo tengo un mal presentimiento general al respecto".

Persona A:"Pero al menos garantiza que descargarás uno nuevo si se modifica.Lo peor que puede pasar es que descargas más a menudo de lo necesario y cualquiera que sepa que no tiene que preocuparse por ello puede simplemente desactivarlo".

Persona B:"Sí, eso tiene sentido.Probablemente esté bien en la mayoría de los casos y parece mejor que las alternativas fáciles".

Descargo de responsabilidad:No tengo ningún conocimiento interno sobre lo que podrían haber estado pensando los implementadores de Apache.Todo esto son sólo conjeturas hechas a mano y tratando de inventar una historia plausible.Pero ciertamente he visto suceder este tipo de cosas con bastante frecuencia.

Nunca se sabe qué fue lo que no se les ocurrió (en este caso, que los servidores redundantes con equilibrio de carga que sirvieran los mismos archivos era más típico que tener que preocuparse por las colisiones de tamaño y tiempo).El equilibrador de carga no forma parte de Apache, lo que facilita dicha supervisión.

Además, el modo de falla aquí es que no hiciste un uso perfectamente eficiente del caché (NO que obtuviste datos incorrectos), lo cual podría decirse que es mejor, aunque molesto.Lo que sugiere que incluso si pensaran en ello, podrían asumir razonablemente que alguien con suficiente interés para configurar un balanceador de carga también estaría de acuerdo en ajustar sus detalles de configuración.

PD:No se trata de estándares.Nada especifica cómo se debe calcular la etag, solo que debería ser suficiente para saber si el contenido ha cambiado, con alta probabilidad.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top