Post-Redirect-Get


Le modèle post-redirect-get ou modèle PRG désigne une approche de développement qui évite les contenus dupliqués lors de l’envoi de formulaires et met à disposition des utilisateurs une interface plus intuitive. Le modèle post-redirect-get permet la mise en place de signets, de fragments d’URL et soutient le rechargement d’un site Web qui requiert et envoie des données de formulaire – sans créer de contenu dupliqué ou presque dupliqué (near duplicate content).

Le modèle PRG est souvent mis en place par les grandes boutiques en ligne afin de permettre la délimitation des catégories de produits à l’aide de la navigation à facettes et de soulager le budget d'exploration. Du point de vue du webdesign et du référencement, l’utilisation du modèle PRG est recommandée afin d’éviter le contenu dupliqué, de mettre à disposition des URL sécables et de préserver les ressources d’exploration. La mise en place de cette approche de développement requiert des connaissances des requêtes Post et Get dans le protocole HTTP de la version 1.1 et peut, dans certaines circonstances, déboucher sur des balises canoniques et des mentions noindex.

Informations générales

Le contexte de l’utilisation du modèle PRG est le suivant : lors de la transmission des données de formulaire à travers une requête Post http, cette requête peut être soumise plusieurs fois auprès du serveur si l’utilisateur qui envoie la requête recharge le formulaire à l’aide de la touche F5 ou du bouton Rafraîchir. Par la suite, des formulaires web peuvent être envoyés deux fois et des commandes peuvent être passées en double. Afin d’éviter ces doubles contenus, il est possible d’utiliser les schémas PRG : à la place d’un site web présentant des doubles contenus est affiché un site web livré à l’aide des requêtes Post et de redirection.

Mode de fonctionnement

Lorsqu’un client consulte et remplit un formulaire en ligne, ce dernier est généralement transmis au serveur à l’aide d’une requête Post. Le serveur effectue une modification de la base de données et enregistre les informations issues du formulaire en ligne. En règle générale, le serveur renvoie une page de confirmation au client. En cas d’erreurs ou de saisies invalides, un formulaire qui informe l’utilisateur de ces erreurs s’affiche. L’utilisateur corrige les informations et clique sur Envoyer : les informations correctes sont envoyées au serveur. Dans le cas où l’utilisateur devait charger à nouveau le formulaire à cet instant, il en résulterait une transmission de données supplémentaire et non désirée d’entrées secondaires depuis la base de données.

C’est là que le modèle PRG entre en scène : après la saisie dans la banque de données, une redirection est envoyée au client. Le client envoie ensuite une requête Get au serveur, qui renvoie à son tour une page de confirmation. Si l’utilisateur doit à nouveau charger le site web, seule une autre requête Get est envoyée au serveur. À la place d’une modification de la banque de données à l’aide d’une requête Post, l’utilisateur reçoit la page de confirmation : sa requête a déjà eu lieu et le nouveau chargement du formulaire en ligne n’entraîne aucun contenu dupliqué.

Le modèle PRG est composé de deux requêtes http et d’une redirection qui référencent les résultats modifiés. Ce modèle permet de procéder au traitement sémantiquement correct des requêtes Post et Get dans le protocole http 1.1.

  • POST : dans le cadre de la requête Post, un formulaire est envoyé au serveur et l’entrée de la banque de données est modifiée.
  • Redirection : suite à une requête Post, le site web adéquat contenant les données modifiées est affiché au client au moyen d’une directive de redirection (HTTP 303).
  • GET : le client demande une page de confirmation. En cas de nouveau chargement, celui-ci est effectué sans modification de la banque de donnée ni création d’un éventuel contenu en double.

Application pratique

Dans la pratique, la mise en place du modèle PRG dépend de la langue de programmation utilisée sur la page du serveur et du système de gestion du contenu. Une solution en PHP peut être la suivante : le formulaire en ligne est ici intitulé echo.php, il doit être généré et le serveur de traitement doit soutenir l’analyse syntaxique PHP – et plus particulièrement utiliser le PHP en tant que langage du serveur. Par exemple, le premier chargement du fichier est déclenché par un utilisateur qui navigue sur le site www.exemple.fr/echo.php. Le code HTML contenu dans le fichier est affiché. L’utilisateur saisit ensuite des données et appuie sur la touche Entrée. Les données saisies sont transmises au serveur sous forme de modifications de la banque de données et livrées au client via la requête Get. Même en cas de requête Get supplémentaire, la saisie reste actuelle, étant donné que les contenus modifiés sont conservés dans la session de connexion. Il en résulte un site web HTML qui contient la saisie en question mais qui est affiché à travers une requête Get – et ne crée pas de contenu dupliqué à travers une requête Post supplémentaire. 

<?php
    session_start();

    $echoedShout = "";

    if(count($_POST) > 0) {
        $_SESSION['shout'] = $_POST['shout'];

        header("HTTP/1.1 303 See Other");
        header("Location: http://$_SERVER[HTTP_HOST]/echo.php");
        die();
    }
    else if (isset($_SESSION['shout'])){
        $echoedShout = $_SESSION['shout'];

        /*
            Source code modifié dans la base de données.
        */

        session_unset();
        session_destroy();
    }
?>

<!DOCTYPE html>
<html>
<head><title>Exemple de modèle PRG dans le PHP</title>

<body>
    <?php echo "<p>$echoedShout</p>" ?>
    <form action="echo.php" method="POST">
        <input type="text" name="shout" value="" />
    </form>
</body>
</html>

Importance pour le référencement

Le modèle PRG est conseillé par les webdesigners et les spécialistes du SEO dans certains cas. Dans le détail, son application dépend de nombreux facteurs différents, liés à la technologie du serveur. Le CMS, les langages de programmation du serveur et les différentes versions de PHP ou d’ASP.NET peuvent entraîner des erreurs et compliquer la mise en place. En particulier dans le cadre d’applications telles que la navigation à facettes, il est recommandé d’accorder une attention toute particulière aux ressources mises à disposition des utilisateurs et des moteurs de recherche. Dans certains cas particuliers, des balises canoniques, des notifications noindex et des basiques du SEO, comme par exemple des URL parlantes, peuvent constituer une référence pour une utilisation du modèle PRG qui ne soit pas à sens unique. Dans le cas de la navigation à facettes, le budget d’exploration[1] peut également être limité à une certaine mesure.

Référence

  1. ↑ Le crawl budget de Google : comment il influence la visibilité de votre site web, Ryte Magazine, ouvert le 31.07.2017

Lien web

Récupérée de « https://fr.ryte.com/wiki/index.php?title=Post-Redirect-Get&oldid=4394 »

Category