Considérations sur l'en-tête HTTP Content-MD5

12

Nous discutons de l'opportunité d'utiliser l'en-tête Content-MD5.

Avantages:

  • Le CMS nous permet de l'inclure facilement avec un minimum de frais généraux (réponses mises en cache dans 80% + des cas).
  • Cela ajouterait une autre couche de protection contre les problèmes.

Les inconvénients:

  • L'en-tête Content-Length est toujours présent (même sur les pages créées dynamiquement), le client ne devrait donc pas avoir besoin d'une autre forme de validation.
  • Jusqu'à présent, nous ne connaissons aucun problème causé par la corruption.
  • Les vérifications MD5 ajoutent une latence aux temps de chargement des pages Web.

Points:

  • Certains types de supports incluent-ils leur propre forme de résumé qui rend cela inutile?
  • Si TCP le propose déjà, pourquoi a-t-il été inclus dans la norme HTTP?
  • Quelles sont les utilisations réelles existantes?
  • Le contrôle MD5 est-il négligeable?

Ce n'est pas vraiment un problème pour que cela soit ajouté aux tests unitaires et implémenté, environ une heure de travail; cependant, si cela est préjudiciable, nous voulons qu'il soit ajouté aux tests de détection de niveau supérieur utilisés dans les "contrôles de santé" du site Web.

http http-headers headers Metalshark
la source

Réponses:

10

TCP a déjà une correction d'erreur, mais cela ne vous aide que sur la couche TCP. Un proxy HTTP ou un équilibreur de charge intermédiaire peut corrompre les données de la couche HTTP, puis les retransmettre. Un HTTP MD5 permet de détecter cette corruption. La raison pour laquelle personne ne parle vraiment de ce besoin est que le problème est vraiment très rare; la plupart des proxys HTTP, etc. "fonctionnent".

Les RFC font allusion à la sécurité. À mon humble avis, c'est si faible qu'il faut l'ignorer - si vous avez besoin d'une réelle sécurité et confidentialité, vous avez besoin du HTTPS.

Certains types de supports incluent-ils leur propre forme de résumé qui rend cela inutile?

Rien de vraiment bon. Mais quelques erreurs dans les photos, la vidéo en streaming, etc. seront souvent imperceptibles pour les humains.

Je dirais que cela dépend du cas d'utilisation:

  • Pour les services Web basés sur REST, un résumé ajoute une couche utile de correction d'erreur supplémentaire. Voir cet échec AWS comme exemple .
  • Pour les applications traitant des données critiques sur HTTP simple, cela vaut la peine d'être implémenté. Content-MD5 donne aux clients la possibilité de vérifier l'intégrité de la transmission de bout en bout.
  • Pour les sites Web «normaux» proposant du texte et des médias de valeur «normale», l'en-tête Content-MD5 ne sert à rien. Et honnêtement, je ne sais même pas combien de navigateurs traditionnels (PC, en particulier mobiles) le prennent en charge.
Jesper M
la source
1
Ce cas de défaillance AWS est vraiment insidieux. Cela fait quelques années, mais c'est vraiment un exemple fascinant d'un mode de défaillance auquel je n'aurais jamais pensé. Très intéressant à surveiller lors de l'utilisation du stockage de données à distance. Je m'interroge sur certaines des solutions NoSQL et comment elles gèrent ces problèmes.
artlung
Cela rend assez facile de transmettre la décision au client. Une option comme celle-ci peut désormais être proposée comme un "bon à avoir" mais pas comme un critère essentiel. Si Amazon peut déployer un équilibreur de charge et provoquer ces erreurs, il est susceptible de se produire quelque part et rien ne semble pire qu'un site Web incohérent.
Metalshark
Cela dépend vraiment de l'emplacement du bit inversé. Si c'est le bit le moins significatif, alors il sera imperceptible. Mais il y a une énorme différence entre les couleurs rgb(255, 0, 0)et rgb(127, 0, 0). Avec la vidéo brute, une corruption d'un seul pixel sera moins perceptible car elle est à l'écran pendant un bref instant, mais comme la plupart des vidéos en ligne utilisent des algorithmes de compression très efficaces, un seul bit retourné peut entraîner la corruption ou le déplacement de la moitié de l'image à travers le écran.
Lèse majesté du
De plus, comme vous l'avez dit, les banques devraient simplement utiliser HTTPS, donc n'y a-t-il pas lieu qu'elles l'utilisent Content-MD5non plus, car SSL / TLS fournit déjà un résumé des messages au niveau de la couche application?
Lèse majesté
1
@ Lèse majesté: Concernant les erreurs de bits, je suis d'accord dans le cas abstrait. Mais rappelez-vous que la plupart des vidéos en streaming fx utilisent un transport spécifique à l'application sur UDP ou TCP pour donner le `` bon '' compromis entre la correction d'erreurs et la vitesse - et la vidéo en streaming ne serait donc pas un cas d'utilisation pour Content-MD5. Concernant les banques devraient utiliser HTTPS, je suis d'accord, et je reformule pour le rendre plus clair.
Jesper M
1

Les vérifications MD5 ajoutent une latence aux temps de chargement des pages Web.

Si vrai (et la latence n'est pas entièrement triviale), je dirais que cela n'en valait pas la peine.

En général, je crois, le dernier en-tête modifié est le plus couramment utilisé pour déterminer si une page a changé. En supposant que vous y fournissiez une valeur significative, je ne vois pas la nécessité de l'en-tête content-md5.

Kris
la source