Quelles caractéristiques techniques pourrais-je inclure dans ma page de traitement des erreurs 404 Fichier introuvable?

Question

J'ai une page de gestion des erreurs 404 personnalisée

Il recherche l'URL dans une table de base de données et redirige s'il y a une cible appropriée. Les URL sont enregistrées, avec la redirection fournie (le cas échéant) et notre application a un rapport d'administration pour montrer quelles URL sont attrapées, permettant au client d'en configurer d'autres.

Nous avons un seul dossier Images spécifique, mais nous obtenons des demandes d'image avec des chemins malformés. Où nous pouvons trouver un nom d'image correspondant dans/IMAGES/nous retournons cela. Devrais-je utiliser un 301? (nous retournons actuellement un 200)

Nous soulignons ces derniers sur le rapport d'Admin - parce que la probabilité est qu'il y a une erreur dans le CMS ou un email en bloc ou quelque chose, et en redirigeant nous masquons juste le problème (et le fixant Je pense que nous devrions retourner une image fictive quand nous obtenons un 404 sur un JPG/GIF/PNG manquant? Actuellement, nous retournons 404 résultats et une page désolée en HTML - ce qui me semble un peu stupide, le navigateur de l'utilisateur ferait-il quelque chose d'utile avec une image retournée s'il y a un code de réponse 404? Je me demande également si le retour d'une image "Image introuvable, visitez www.example.com" serait utile (peut-être plus particulièrement si mon domaine n'est PAS le référent!). Alors la personne inutile qui incorpore nos images dans leur site, à tort à cela !, pourrait au moins nous conduire un peu de trafic.

De même devrais-je retourner quelque chose d'utile si je reçois une requête 404 pour des fichiers JS ou CSS? Je pense à DEV, au moins, il serait utile de savoir que nous avons gaffé. Parfois, le fichier manquant peut être suffisamment obscur, dans son utilisation, que son absence est manquée dans le contrôle qualité. (Je suppose que quelqu'un OUGHT pour le remarquer dans les 404 logs!), Mais je pense à mettre BODY à quelque chose de massif, ou une alerte dans le fichier .JS retourné, pourrait aider dans DEV. Dans Googling autour de ce aujourd'hui, je suis tombé sur la suggestion qu'une chaîne de requête malformée pourrait renvoyer une "400 Bad Request" et une chaîne de requête bien formée, mais où un paramètre a une valeur invalide (par exemple code produit introuvable) pourrait être traité comme un 404. Si je fais cela et que je retourne aussi du contenu (par exemple une page d'explication), l'utilisateur verra-t-il cela, ou son navigateur pourrait-il le remplacer par une page d'erreur 404 en boîte? (J'avais le sentiment qu'une version antérieure d'IE l'avait fait?)

Toutes les idées ont été appréciées.

(ASP classique/IIS dans mon cas, mais nous espérons que la question est générique)

Modifier: Je me demande aussi si quelqu'un fait anythign spécial avec des choses qui ressemblent les tentatives de hack comme connus?

• http://www.example.com:80/ admin/phpmyadmin/scripts/setup.php
• http://www.example.com:80/ admin/pma/scripts /setup.php
• http://www.example.com:80/ admin/scripts/setup.php
• http://www.example.com:80/ db/scripts/setup .php
• http://www.example.com:80/ dbadmin/scripts/setup.php
• http://www.example.com:80/ myadmin/scripts/setup.php
• http://www.example.com:80/ mysql/scripts/setup.php
• http://www.example.com:80/ mysqladmin/scripts/setup.php
• http://www.example.com:80/ phpadmin/scripts/setup.php
• http://www.example.com:80/ phpMyAdmin/scripts/setup.php
• http://www.example.com:80/ phpmyadmin1/scripts/setup.php
• http://www.example.com:80/ phpmyadmin2/scripts/setup.php
• http://www.example.com:80/ pma/scripts/setup.php
• http://www.example.com:80/ web/scripts/setup.php

et ces "palpeurs":

• http: //www.example.com: 80/_vti_bin/owssvr.dll ...
• http: //www.example.com: 80/MSOffice/cltreq.asp ...

Edit2: Désolé, nous espérons que le dernier après que.

Devrais-je attribuer un ID de session? Cela me permettrait de savoir si l'utilisateur revient avec quelque chose de plus intelligent lors d'une seconde tentative (ce qui pourrait nous amener à ajouter une entrée à notre table de redirection). Création d'une session implique la création d'un enregistrement de session dans la base de données et d'autres choses, donc n'est pas aussi "bon marché" que de donner une erreur 404

Answer 1

J'ai une fois créé une page Web qui génère dynamiquement des images. Le problème était comment propager des erreurs quand l'image n'a pas pu être rendue.

La solution, que je trouve très bonne, était simplement d'imprimer le message d'erreur dans l'image elle-même. Alors vous pourriez HREF l'image et si cela n'a pas fonctionné, vous obtiendriez le message d'erreur imprimé. Mieux que de simplement retourner une image invalide.

Pour les fichiers JS, vous pouvez faire faire la même chose, mais je ne sais pas si ce serait un bon design. Je ne pense pas que même retourner un document texte vide serait bon dans ce cas. Vous pourrait retourner les messages d'erreur dans les boîtes d'alerte, et les accrocher dans votre application principale, mais je suppose que c'est plus utile pour les développeurs, et pas les utilisateurs en général. (Cela dépend de qui sont vos utilisateurs) Je pense que la même chose vaut pour CSS. Pour les messages d'erreur en général, si vous voulez juste savoir qu'une URL invalide a été atteinte, vous pouvez soit chercher dans les journaux du serveur, soit masquer un script derrière les URLs JS/CSS qui ont enregistré un message informatif quelque part. Enfin, n'oubliez pas que les codes HTTP sont faits pour une raison. Vous pouvez vous attendre à ce que les clients gèrent mieux les codes d'erreur HTTP valides que les fausses et apparemment bonnes (d'un point de vue HTTP).En d'autres termes, vous pourriez utiliser ceci à votre avantage et répondre avec des codes d'erreur HTTP plus spécifiques dans des situations où les normales ne sont pas adéquates.