# Documentation Django 3.1.9.dev

# Décorateurs de vue

Django fournit plusieurs décorateurs afin de permettre aux vues de prendre en charge différentes fonctionnalités HTTP.

Voir Décoration de la classe pour savoir comment utiliser ces décorateurs avec les vues fondées sur des classes.

## Méthodes HTTP autorisées

Les décorateurs présents dans `django.views.decorators.http` peuvent être utilisés pour restreindre l’accès à une vue en se basant sur la méthode utilisée lors de la requête. Ces décorateurs renvoient une instance de `django.http.HttpResponseNotAllowed` si les conditions ne sont pas remplies.

`require_http_methods`(request_method_list)

  Décorateur exigeant que l’accès à une vue se fasse via certaines méthodes HTTP seulement. Exemple :

      from django.views.decorators.http import require_http_methods

      @require_http_methods(["GET", "POST"])
      def my_view(request):
          # I can assume now that only GET or POST requests make it this far
          # ...
          pass

  Remarquez que les noms de méthodes HTTP doivent être en majuscules.

`require_GET`()

  Décorateur exigeant que la vue n’accepte que la méthode GET.

`require_POST`()

  Décorateur exigeant que la vue n’accepte que la méthode POST.

`require_safe`()

  Décorateur exigeant que la vue n’accepte que les méthodes GET et HEAD. Ces méthodes sont généralement considérées « sans risque » car elles ne devraient rien faire d’autre mis à part retourner la ressource demandée.

  Note

  Les serveurs Web devraient retirer automatiquement le contenu des réponses aux requêtes HEAD en prenant soin de laisser les en-têtes inchangés, vous pouvez ainsi traiter les requêtes HEAD comme des requêtes GET dans vos vues. Étant donné que certains programmes, tels que les vérificateurs d’hyperliens, se basent sur les requêtes HEAD, il peut être préférable d’utiliser `require_safe` à la place de `require_GET`.

## Traitement conditionnel de vue

Les décorateurs suivants présents dans `django.views.decorators.http` peuvent être utilisés pour contrôler le comportement du cache sur certaines vues.

`condition`(etag_func=None, last_modified_func=None)

`etag`(etag_func)

`last_modified`(last_modified_func)

  Ces décorateurs peuvent être utilisés pour générer des en-têtes `ETag` et `Last-Modified`. Voir traitement conditionnel de vue.

## Compression GZip

Les décorateurs présents dans `django.views.decorators.gzip` contrôlent la compression du contenu vue par vue.

`gzip_page`()

  Ce décorateur compresse le contenu si le navigateur autorise la compression gzip. Il déclare l’en-tête `Vary` en conséquence, de façon à ce que la mise en cache dépende de l’en-tête `Accept-Encoding`.

## En-têtes Vary

Les décorateurs présents dans `django.views.decorators.vary` peuvent être utilisés pour contrôler la mise en cache reposant sur certains en-têtes des requêtes.

`vary_on_cookie`(func)

`vary_on_headers`(*headers)

  L’en-tête `Vary` définit quels en-têtes de requête un mécanisme de cache doit prendre en considération pour générer sa clé de cache.

  Voir utilisation des en-têtes vary.

## Mise en cache

Les décorateurs présents dans `django.views.decorators.cache` contrôlent la mise en cache aux niveaux serveur et client.

`cache_control`(**kwargs)

  Ce décorateur complète l’en-tête `Cache-Control` de la réponse en y ajoutant tous les paramètres nommés. Voir `patch_cache_control()` pour les détails sur la transformation.

`never_cache`(view_func)

  Ce décorateur ajoute un en-tête `Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private` à une réponse pour indiquer que la page ne doit jamais être mise en cache.

  Changed in Django 3.0:

  La directive `private` a été ajoutée.