web-dev-qa-db-fra.com

Gestion des codes d'erreur 404/410 appropriés sur un site géré par une base de données dynamique

un développeur avec lequel je travaille a des difficultés à traiter 404 erreurs sur des pages générées dynamiquement (elles sont créées lorsque la demande est faite en interrogeant la base de données pour voir si le contenu existe)

Il m'a dit (en paraphrasant) qu'il est trop tard pour signaler l'erreur, car le chargement de la page a déjà commencé au moment où il découvre si la page existe ou non. Je ne suis pas vraiment sûr de savoir comment réagir sans trop savoir comment PHP ou Apache fonctionne

Quelqu'un d'autre a-t-il rencontré ce type de problème et si tel est le cas, comment puis-je le résoudre et commencer à traiter correctement les erreurs 404 ou 410 sur ce contenu supprimé?

Actuellement, les demandes sont redirigées (nous ne savons pas si 302 ou 301 pour le moment) vers notre page 404.php. Est-ce une alternative acceptable?

Merci :)

phpapacheredirects404error
1
Drewdavid

Si le code est à mi-chemin de l'impression de la page, il est en effet trop tard pour envoyer un statut 404. Tous les codes d'état doivent être définis en tant qu'en-tête HTTP, envoyés avant tout code HTML.

De ce fait, il est généralement utile de structurer le code de manière à ce qu'il rassemble les informations nécessaires à la création de la page avant d'envoyer du code HTML au client. Votre développeur ne l’a peut-être pas configuré de cette façon, malheureusement.

La seule chose qui ne correspond pas à l'explication de votre développeur: les redirections 301 et 302 sont également spécifiées en tant que codes d'état HTTP à envoyer avant tout code HTML. S'il n'est pas trop tard pour envoyer une redirection, il ne devrait pas être trop tard pour envoyer un en-tête 404. Le manuel PHP pour les en-têtes contient des exemples de redirections et de 404. Ils sont très similaires.

La redirection vers une page 404 plutôt que d'afficher directement une page 404 est très courante. La configuration Apache rend cela très facile (même parfois par erreur). En conséquence, les araignées des moteurs de recherche doivent savoir comment faire face à une telle situation. Ce n'est pas idéal, mais cela ne devrait pas causer d'énormes problèmes.

1
Stephen Ostermiller

Selon RFC 2616 (section 4.2) :

L'ordre dans lequel les champs d'en-tête avec des noms de champs différents sont reçus n'est pas significatif. Cependant, il est de "bonne pratique" d'envoyer d'abord les champs d'en-tête général, suivis des champs d'en-tête de requête ou d'en-tête de réponse, et se terminant par les champs d'en-tête d'entité.

Si vous êtes développeur, vous devez penser différemment et faire face à un problème comme celui-ci. Ce style de codage doit être déterminé au début du développement. Beaucoup de gens aiment coder PHP pour pouvoir entrer et sortir de HTML. Au point HTML (même un espace) ou PHP a une instruction echo ou print, headers sont fermés (pas les en-têtes HTML, mais les en-têtes qui indiquez au navigateur ce qui va arriver, une image, une page HTML, une redirection, etc.).

Code PHP typique des développeurs locaux: 

<h2>Welcome <?php echo $Username; ?></h2>
<p> We were considering your application(s) for <?php echo $specialty; ?>.
We are <?php

  if($accepted==1){
     echo "happy"
  } else {
     echo "sorry"
  }

  ?> to inform you of our decision ...

Une méthode plus efficace et plus flexible

La solution consiste à tout stocker jusqu'à la fin du traitement, puis à vérifier les erreurs et à envoyer une réponse. Une meilleure méthode est:

/*$page string started out here somewhere*/

if(empty($request_id)){
  //code for the 404
} elseif ($request_id < 0)
  //code for the 410
} else {

  switch($accepted){
    case "1":
     $mood = "happy";
    break;
    default:
     $mood = "sorry";

$inner_code = "<h2>Welcome $Username</h2>\n";
$inner_code .= "<p>We were considering your application(s) for $specialty.";
$inner_code .= " We are $mood to inform you of our decision ...";

/*more stuff here*/

$page .= $HTML_header;
$page.=$inner_code;
$page .= $HTML_footer;

print $page;

}

Dans votre cas spécifique

Il semble que beaucoup de développement ait été fait. Si le site a un peu de taille ou de complexité, cela peut poser un problème de budgétisation (si vous utilisez des sous-traitants). Si les programmeurs sont internes, vous devriez pouvoir réécrire le site sans problème (au moins cette partie).

1
AbsoluteƵERØ