Les clients HTTP peuvent envoyer plusieurs en-têtes pour signaler au serveur des copies de ressources qu’ils ont déjà rencontrées. C’est fréquemment employé lors de l’obtention d’une page Web (par une requête HTTP GET) pour éviter d’envoyer toutes les données quand le client en a déjà récupéré une partie. Cependant, les mêmes en-têtes peuvent être utilisés par toutes les méthodes HTTP (POST, PUT, DELETE, etc.).
Pour chaque page (réponse) que Django renvoie depuis une vue, il est susceptible de définir deux en-têtes HTTP : l’en-tête ETag et l’en-tête Last-Modified. Ces en-têtes sont facultatifs dans les réponses HTTP. Ils peuvent être définis par la fonction de vue ou il est possible de compter sur l’intergiciel CommonMiddleware pour définir l’en-tête ETag.
Lorsqu’un client demande une nouvelle fois la même ressource, il peut envoyer avec la requête un en-tête tel que If-modified-since ou If-unmodified-since contenant la date de dernière modification qu’il a reçue, ou If-match ou If-none-match contenant la dernière valeur ETag qu’il a reçue. Si la version actuelle de la page correspond à la valeur ETag envoyée par le client ou que la ressource n’a pas été modifiée entre temps, le serveur peut renvoyer un code de statut 304 au lieu d’une réponse complète, indiquant par là au client que rien n’a changé. En fonction de l’en-tête, si la page a été modifiée ou ne correspond pas au contenu ETag envoyé par le client, un code de statut 412 (Precondition Failed) peut être renvoyé.
Dans les cas où vous avez besoin d’un contrôle plus fin, vous pouvez utiliser les fonctions de traitement conditionnel par vue.
\n\nconditionLien vers cette rubrique#Parfois (et assez souvent en réalité), vous pouvez créer des fonctions pour calculer rapidement la valeur ETag ou la date de dernière modification d’une ressource, sans devoir procéder à toutes les opérations nécessaires à la construction complète de la vue. Django peut ensuite utiliser ces fonctions pour fournir une option de « court-circuitage rapide » du traitement de la vue. Par exemple pour indiquer au client que le contenu n’a pas été modifié depuis la requête précédente.
\nThese two functions are passed as parameters to the\ndjango.views.decorators.http.condition decorator. This decorator uses\nthe two functions (you only need to supply one, if you can’t compute both\nquantities easily and quickly) to work out if the headers in the HTTP request\nmatch those on the resource. If they don’t match, a new copy of the resource\nmust be computed and your normal view is called.
La signature du décorateur condition correspond à ceci :
condition(etag_func=None, last_modified_func=None)\nLes deux fonctions, celle pour calculer la valeur ETag et celle pour la date de dernière modification, reçoivent l’objet request entrant ainsi que les mêmes paramètres, dans le même ordre, que la fonction de vue qu’elles enveloppent. La fonction de rappel last_modified_func doit renvoyer une valeur date/heure standard indiquant la date de dernière modification de la ressource ou None si la ressource n’existe pas. La fonction de rappel du décorateur etag doit renvoyer une chaîne représentant la valeur Etag de la ressource, ou None si la ressource n’existe pas.
Il est probablement plus adéquat d’expliquer la façon d’utiliser cette fonctionnalité par un exemple. Admettons que vous ayez ces deux modèles représentant un système simple de blog :
\nimport datetime\nfrom django.db import models\n\nclass Blog(models.Model):\n ...\n\nclass Entry(models.Model):\n blog = models.ForeignKey(Blog)\n published = models.DateTimeField(default=datetime.datetime.now)\n ...\nSi la page d’accueil affichant les derniers articles de blog ne change que lorsque vous ajoutez un nouvel article, vous pouvez calculer très rapidement la date de dernière modification. Vous avez besoin de la date published la plus récente de chaque article associé à ce blog. Une façon de le faire serait :
def latest_entry(request, blog_id):\n return Entry.objects.filter(blog=blog_id).latest("published").published\nVous pouvez dès lors utiliser cette fonction pour fournir une détection rapide d’une page d’accueil inchangée :
\nfrom django.views.decorators.http import condition\n\n@condition(last_modified_func=latest_entry)\ndef front_page(request, blog_id):\n ...\nEn règle générale, si vous pouvez fournir des fonctions à la fois pour le calcul de la valeur ETag et la date de dernière modification, il est bien de le faire. On ne connaît pas à l’avance les en-têtes qu’un client HTTP donné va envoyer, on peut donc s’attendre à devoir gérer les deux cas de figure. Cependant, il peut arriver qu’une seule des deux valeurs soit facile à calculer et Django fournit donc des décorateurs qui ne gèrent que la valeur ETag ou que la date de dernière modification.
Les décorateurs django.views.decorators.http.etag et django.views.decorators.http.last_modified reçoivent le même type de fonction que le décorateur condition. Leur signature est :
etag(etag_func)\nlast_modified(last_modified_func)\nNous pourrions écrire l’exemple précédent qui n’utilisait que la fonction de dernière modification en choisissant l’un de ces décorateurs :
\n@last_modified(latest_entry)\ndef front_page(request, blog_id):\n ...\n…ou :
\ndef front_page(request, blog_id):\n ...\nfront_page = last_modified(latest_entry)(front_page)\nconditionLien vers cette rubrique#Il pourrait paraître plus élégant pour certaines personnes d’essayer d’enchaîner les décorateurs etag et last_modified pour tester les deux pré-conditions. Cependant, l’effet produit serait faux.
# Bad code. Don't do this!\n@etag(etag_func)\n@last_modified(last_modified_func)\ndef my_view(request):\n # ...\n\n# End of bad code.\nLe premier décorateur n’a aucune conscience du second et pourrait répondre que la réponse n’a pas été modifiée même quand le second décorateur en déciderait autrement. Le décorateur condition utilise les deux fonctions de rappel de concert pour prendre la bonne décision.
Le décorateur condition est utile au-delà des requêtes GET et HEAD (les requêtes HEAD sont similaires aux requêtes GET dans cette optique). Il peut aussi être utilisé pour faire les vérifications nécessaires pour les requêtes POST, PUT et DELETE. Dans ces cas de figure, l’idée n’est pas de renvoyer une réponse « non modifiée », mais d’indiquer au client que la ressource qu’ils tentent de modifier a subi des modifications dans l’intervalle.
Par exemple, considérez l’échange suivant entre un client et un serveur :
\nLe client demande /foo/.
Le serveur répond avec un contenu dont la valeur ETag vaut "abcd1234".
Le client envoie une requête HTTP PUT vers /foo/ pour mettre à jour la ressource. Il envoie également un en-tête If-Match: "abcd1234" pour indiquer la version qu’il tente de mettre à jour.
Server checks to see if the resource has changed, by computing the ETag\nthe same way it does for a GET request (using the same function).\nIf the resource has changed, it will return a 412 status code,\nmeaning « precondition failed ».
Le client envoie une requête GET vers /foo/ après la réception de la réponse 412 afin de récupérer une version mise à jour du contenu avant de le mettre à jour.
La chose importante démontrée par cet exemple est que les mêmes fonctions peuvent être utilisées pour calculer les valeurs ETag et date de dernière modification dans toutes les situations. En fait, vous devez utiliser les mêmes fonctions afin que les mêmes valeurs soient renvoyées à chaque fois.
Vous pouvez constater que Django fournit déjà une gestion conditionnelle de GET simple et directe via les intergiciels django.middleware.http.ConditionalGetMiddleware et CommonMiddleware. Bien qu’elles soient certainement simple d’utilisation et adaptées à de nombreuses situations, les fonctionnalités de ces intergiciels présentent des limites quant à un usage avancé :
Elles sont appliquées globalement à toutes les vues d’un projet.
Elles ne vous économisent pas le travail de génération de la réponse elle-même, ce qui peut être coûteux.
Elles ne sont adaptées qu’aux requêtes HTTP GET.
Vous devriez choisir ici l’outil le plus approprié à votre problème particulier. Si vous arrivez à calculer rapidement les valeurs ETag et de date de dernière modification et que certaines vues prennent du temps à produire leur contenu, vous devriez envisager d’utiliser le décorateur condition présenté dans ce document. Par contre, si tout fonctionne déjà de manière assez fluide, restez-en à la solution des intergiciels et vous continuerez de réduire la quantité de trafic réseau en direction des clients dans les cas où les contenus des vues n’ont pas changé.