J'ai remarqué que de nombreux clients http, y compris Firefox et Chrome, n'autorisent pas les téléchargements de fichiers pour les codes de réponse http avec 4XX et 5XX. Cependant, certains clients autorisent ces téléchargements, comme curl et wget (avec l'option --content-on-error ).
Chrome et Firefox ne fournissent pas de bons messages d'exception.
Chrome échoue avec ERR_INVALID_RESPONSE . Firefox échoue avec Fichier non trouvé . Comme indiqué ci-dessus pour le curly et le wget fonctionnent pour la même URL.
Je me demandais s'il existe une spécification définissant le comportement correct dans ce cas? Existe-t-il de bonnes raisons pour lesquelles la demande ne peut pas être traitée par Chrome et Firefox? De plus, il semble étrange qu'ils ne fournissent pas de commentaires appropriés.
Je pense que dans la plupart des cas, un téléchargement pour les demandes échouées n'a aucun sens, mais dans certains cas, ce serait utile. Un bon exemple où le téléchargement d'un fichier même en cas d'erreur serait s'il existe un client qui ne communique qu'avec le serveur en utilisant un format tiers. Le client devra télécharger un fichier généré pour la demande. En cas d'erreur, le client doit télécharger un fichier contenant la description de l'erreur.
Par exemple, les états RFC7231
Messages de réponse avec un code d'état d'erreur contiennent généralement une charge utile qui représente la condition d'erreur, telle qu'il décrit l'état d'erreur et les prochaines étapes suggérées pour le résoudre.
La classe de code d'état 4xx (Erreur client) indique que le client semble avoir commis une erreur. Sauf en réponse à une demande HEAD, le le serveur DEVRAIT envoyer une représentation contenant une explication du situation d'erreur, et s'il s'agit d'un problème temporaire ou permanent état. Ces codes d'état s'appliquent à toute méthode de demande. Les agents utilisateurs DEVRAIENT afficher toute représentation incluse à l'utilisateur.
Cela n'interdit pas le téléchargement en cas d'erreur.
Modifier en raison de la première réponse:
Je ne pense pas que ce comportement soit convivial et je ne pense pas que la convivialité en soit vraiment la raison. Par exemple, il serait beaucoup plus logique d'afficher le code d'erreur et le message d'erreur (fournis dans l'en-tête) à l'utilisateur. Ou au moins indiquer l'erreur avec un message d'erreur comme "impossible de télécharger le fichier, car le serveur a répondu avec une erreur". Il peut y avoir des serveurs qui ne peuvent répondre qu’avec XML ou tout autre format de fichier aléatoire.
Ce qui me dérange le plus, c'est que les deux navigateurs répondent par des erreurs différentes mais arbitraires qui n'indiquent aucune information sur le problème sous-jacent.
4XX: Pourquoi supposeriez-vous un téléchargement de fichier si votre client faisait quelque chose de mal?
Si nous supposons qu'une API a un point de terminaison qui répond avec un certain format de fichier, il est juste de supposer que le message d'erreur incluant un indice de ce que le client a mal fait est fourni dans ce format. Le fichier peut donc aider à corriger l'erreur du client.
5 Réponses :
Je n'ai connaissance d'aucune spécification pour ce sujet. Le comportement doit être aussi convivial que possible.
4XX: Pourquoi supposeriez-vous un téléchargement de fichier si votre client a fait quelque chose de mal? De plus, le logiciel client ne pouvait pas différer entre le cas d'une mauvaise utilisation (par exemple, une URL invalide) et la gestion d'un téléchargement de fichier.
5xx: Comme vous l'avez indiqué, la plupart des API fournissent des informations d'erreur, mais vous ne pouvez pas non plus différer le cas du téléchargement et par exemple une erreur interne fournissant le fichier.
Vous pouvez utiliser ce comportement avec wget et curl comme vous l'avez mentionné, mais ce n'est ni convivial ni pratique pour utiliser une telle API par programmation.
Les informations ci-dessus à l'esprit, Chrome et Firefox essaient simplement d'être conviviaux.
J'espère pouvoir répondre d'une manière ou d'une autre à votre question ou remettre en question l'idée qui la sous-tend. :)
Merci pour votre réponse. J'ai mis à jour ma question. Je ne pense pas du tout que ce comportement soit convivial.
En regardant chrome handle download et non 2xx nous voyons:
// The response code indicates that this is an error page, but we don't // know how to display the content. We follow Firefox here and show our // own error page instead of intercepting the request as a stream or a // download.
Donc Chrome a suivi Firefox, et les deux sont entièrement cohérents avec les RFC, le navigateur sait cette charge utile est une donnée non identifiée relative à une condition d'erreur, donc enregistrez-la en tant que fichier dans la question n'est pas une option. Comme il est en cours de téléchargement, le navigateur ne peut vraisemblablement pas afficher la charge utile, mais dans les deux cas, il lui a été demandé de ne pas le faire, donc l'afficher dans le contexte d'erreur n'est pas une option sûre. Puisqu'il s'agit d'une erreur, il y a également une forte probabilité que l'expéditeur ait combiné une réponse partielle avec un code d'erreur, ce qui signifie que le contenu de la charge utile peut être une représentation incomplète ou corrompue des données d'une réponse 2xx / etc.
Si vous regardez en arrière sur wget, --content-on-error est une option spécifique car ce n'est pas la bonne chose à faire en tant que navigateur général. Un côté client qui fonctionne avec le type de charge utile pourrait examiner les erreurs lorsqu'il interagit directement avec un serveur et wget ne fournit que des options pour vous aider à déboguer une telle interaction. Un navigateur normal a moins de fonctionnalités pour aider à émuler d'autres clients pour le débogage qu'une CLI texte, car une CLI texte existe principalement pour émuler un autre client lors du débogage.
Le commit crrev.com/526475 comprend également une discussion qui a codifié le comportement de Firefox dans les tests de la plate-forme Web.
Merci pour votre réponse. C'est dommage que Chromium ait suivi Firefox. D'autant plus que la décision de Firefox semblait être un correctif. Je viens de trouver le problème pertinent dans le bugtracker de Firefox - bugzilla.mozilla.org/show_bug.cgi? id = 312727
Je me demandais s'il existe une spécification définissant le bon comportement dans ce cas? Y a-t-il de bonnes raisons pour lesquelles la demande ne peut pas être traité par Chrome et Firefox? De plus, il semble étrange qu'ils ne fournissez pas de commentaires appropriés.
Il n'y a pas de spécification de ce type pour cela, mais le membre du projet chrome trouve cela comme un problème trivial et peu susceptible d'être résolu dans un proche avenir. Au lieu de fixer le chrome, ils suggèrent qu'il devrait être corrigé sur le serveur en envoyant le statut HTTP approprié.
Réponse du membre du projet Chromium: " Ce problème est disponible depuis plus d'un an. S'il ne l'est plus important ou semble peu susceptible d'être corrigé, veuillez envisager de le fermer dehors. S'il est important, veuillez trier à nouveau le problème. "
Désolé pour le désagrément si le bogue aurait vraiment dû être laissé comme Disponible .
Vous pouvez consulter plus de détails ici Numéro 479265
Que se passe-t-il sous la surface?
J'ai ensuite vérifié le code source du chrome pour trouver ce qui se passe réellement et j'ai trouvé que pour tout statut non 200 pour les téléchargements, ils lancent simplement ERR_INVALID_RESPONSE Erreur (Réponse du serveur non valide).
Pour résumer, vous devez vivre avec ce comportement du navigateur , il ne va pas être amélioré.
Ces réponses semblent toutes contourner le fondamental ici: vous essayez de donner une interprétation spécifique au navigateur à une erreur dans votre code. De mon point de vue, dans tous les cas associés, votre code échoue d'une manière ou d'une autre sans traitement d'erreur.
Erreur 4xx? Vous avez envoyé une mauvaise requête au serveur, conformément aux règles que vous avez déterminées. Ce n'est pas, techniquement, la faute du navigateur.
Erreur 5xx? Votre serveur a planté et n'a pas généré une jolie erreur. Sur certains types de serveur (Django), une erreur 500 sera un tas d'informations de débogage que vous ne devriez probablement pas montrer à l'utilisateur.
Ainsi, ce que vous demandez est étrange d'un point de vue architectural; vous voulez dissimuler le fait que vous vous êtes trompé en modifiant la réponse du navigateur plutôt que de réparer votre code pour qu'il réponde correctement.
Je ne suis pas d'accord sur les erreurs 4XX. La spécification indique clairement: le serveur DEVRAIT envoyer une représentation contenant une explication de la situation d'erreur, et s'il s'agit d'une condition temporaire ou permanente . Si une API est censée renvoyer un certain type de fichier, il est juste de supposer qu'elle renverra également ce type de fichier en cas d'erreur. Les erreurs 5XX sont autre chose et je peux comprendre que le navigateur n'accepte pas les téléchargements pour les réponses 5XX. D'autre part, pour 5XX, il est courant de fournir un identifiant de journal d'erreurs auquel les utilisateurs peuvent se référer lorsqu'ils contactent le support.
Dans une application Web moderne, vous contrôlez ce qui est envoyé du navigateur au serveur. Nous ne parlons probablement pas d'une requête HTTP brute ici, nous sommes plus susceptibles de traiter une sorte de package JSON malformé. Si l'utilisateur génère lui-même ce package JSON, il tente une sorte d'utilisation abusive ou votre interface utilisateur est terrible. Si ce n'est pas le cas, le package que vous assemblez est mal formé et le décalage entre l'attente et la réalité est généralement sous votre contrôle. Les exceptions étant les erreurs de réseau, qui sont rarement vues.
Cette question ne concerne pas JSON, mais le téléchargement de fichiers.
Qu'est-ce qui déclenche ces téléchargements de fichiers et pourquoi renvoyez-vous des codes d'erreur ET un fichier?
C'est exactement la question, pourquoi il ne faut pas renvoyer un code d'erreur et un fichier.
Si vous donnez à quelqu'un le fichier approprié, le code d'erreur n'est que du bruit; ils ont obtenu ce qu'ils ont demandé, et le navigateur ne devrait pas avoir besoin de s'impliquer - vos journaux côté serveur devraient le faire. Si vous ne donnez pas à quelqu'un le fichier approprié, pourquoi lui donnez-vous le fichier en premier lieu? Il me semble que vous voudrez peut-être rechercher des codes différents plutôt que de remplir la communication que vous voulez dans des codes définis pour votre utilisation comme «Erreurs système ici, creuser». Il y a beaucoup de messages non fatals parmi lesquels choisir, pourquoi ne pas les utiliser?
En s'appuyant sur la réponse de @ lossleader , il semble que Chromium ait décidé de suivre la décision de Firefox de ne pas télécharger de fichiers si la réponse était échec.
Il semble que ce problème ait une histoire. En 2005, un site Web AOL a rencontré un problème qui renvoyait un code d'état 500 et entraînait le téléchargement d'un fichier .exe par les utilisateurs. Il y avait un "correctif" qui renvoie simplement un 404 pour les réponses qui déclenchent un téléchargement et avec des réponses erronées. Le problème correspondant peut être trouvé ici .
Il y a un problème en suspens de 2008, qui se plaint de cette erreur et déclare que ce serait trompeur. Le problème correspondant peut être trouvé ici .
J'ai trouvé une réponse plus détaillée à ce sujet sur Super utilisateur .
Je pense toujours qu'il serait correct d'offrir au moins le choix à l'utilisateur de télécharger le fichier quand même ou au moins d'afficher une page d'erreur plus significative. D'un autre côté, dans la plupart des cas, le téléchargement d'un code de réponse ! = 2XX n'est pas intentionnel et indique une erreur de serveur. Par conséquent, il semble que ce problème ait une faible priorité pour les fournisseurs de navigateurs et semble "ne pas valoir la peine".