recursal/MDN huggingface dataset:
PUT
===

La **méthode HTTP PUT** crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par le contenu de la requête.

La différence entre `PUT` et `POST` tient au fait que `PUT` est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet *de bord*). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

|  |  |
| --- | --- |
| La requête a un corps | Oui |
| Une réponse de succès a un corps | Non |
| Sûre | Non |
| Idempotente | Oui |
| Peut être mise en cache | Non |
| Autorisée dans les formulaires HTML | Non |

Syntaxe
-------


```html
PUT /new.html HTTP/1.1
```

Exemple
-------

### Requête
```

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>Nouveau fichier</p>
```

### Réponses

Si la ressource ciblée ne possède pas de représentation courante et que la requête `PUT` en crée une avec succès, alors le serveur d'origine doit informer l'agent utilisateur en envoyant une réponse `201` (`Created`).
```

HTTP/1.1 201 Created
Content-Location: /new.html
```


Si la ressource ciblée a déjà une représentation et que cette représentation est modifiée avec succès, conformément à l'état de la représentation jointe, alors le serveur d'origine doit envoyer une réponse, que ce soit `200` (`OK`) ou `204` (`No Content`), pour indiquer la réussite de la requête.
```

HTTP/1.1 204 No Content
Content-Location: /existing.html
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # PUT |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `201`
* `204`
CONNECT
=======

La **méthode HTTP `CONNECT`** crée une communication bidirectionnelle avec la ressource demandée. Elle peut être utilisée pour ouvrir un tunnel.

Par exemple, la méthode `CONNECT` peut être utilisée pour accéder à des sites web qui utilisent SSL (HTTPS). Le client demande à un serveur Proxy HTTP de créer un tunnel TCP vers la destination désirée. Le serveur poursuit alors afin d'établir la connexion pour le compte du client. Une fois que la connexion a été établie par le serveur, le serveur Proxy continue de gérer le flux TCP à destination et en provenance du client.

`CONNECT` est une méthode "saut-par-saut".

|  |  |
| --- | --- |
| La requête a un corps | Oui |
| Une réponse de succès a un corps | Oui |
| Sûre | Non |
| Idempotente | Non |
| Peut être mise en cache | Non |
| 
 Autorisée dans les
 formulaires HTML | Non |

Syntaxe
-------
```

CONNECT www.example.com:443 HTTP/1.1
```

Exemple
-------

Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête `Proxy-Authorization` (en-US).
```

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # CONNECT |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* Proxy server
* `Proxy-Authorization` (en-US)
POST
====

La **méthode HTTP `POST`** envoie des données au serveur. Le type du corps de la requête est indiqué par l'en-tête `Content-Type`.

La différence entre `PUT` et `POST` tient au fait que `PUT` est une méthode idempotente. Une requête `PUT`, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes `POST` successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

Une requête `POST` est habituellement envoyée via un formulaire HTML (en-US) et a pour résultat un changement sur le serveur. Dans ce cas, le type du contenu est sélectionné en mettant la chaîne de caractères adéquate dans l'attribut *`enctype` de l'élément `<form>` ou dans l'attribut `formenctype` de l'élément `<input>`, voir celui des éléments `<button>`* :

* `application/`*`x-www-form-urlencoded` : les valeurs sont encodées sous forme de couples clé-valeur séparés par `'&'`, avec un `'='` entre la clé et la valeur. Les caractères non alphanumériques sont percent encoded : c'est la raison pour laquelle ce type de format n'est pas adapté à une utilisation avec des données binaires (utilisez `multipart/form-data` à la place)*
* *`multipart/form-data`*
* *`text/plain`*

Lorsque la requête `POST` est envoyée par un autre moyen qu'un formulaire HTML, par exemple via `XMLHttpRequest`, le corps peut être de n'importe quel type. Comme décrit dans la spécification HTTP 1.1, `la méthode POST` est conçue pour permettre une méthode uniforme couvrant les fonctions suivantes :

* Annotation de ressources existantes
* Publication d'un message sur un tableau d'affichage, un groupe de discussion, une liste de diffusion, ou un groupe similaire d'articles;
* Apport d'un bloc de données, tel que le résultat produit par la soumission d'un formulaire, à un processus de traitement de données;
* Extension d'une base de données au travers d'une opération d'ajout.

|  |  |
| --- | --- |
| La requête a un corps | Oui |
| Une réponse inclut un corps | Oui |
| Sûre | Non |
| Idempotente | Non |
| Peut être mise en cache | Seulement si une information de péremption est incluse |
| 
 Autorisée dans les
 formulaires HTML | Oui |

Syntaxe
-------
```

POST /index.html
```

Exemple
-------

Un formulaire simple utilisant le type de contenu par défaut `application/x-www-form-urlencoded` :
```

POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom
```


Un formulaire utilisant le type de contenu `multipart/form-data` :
```

POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # POST |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Content-Type`
* `Content-Disposition`
204 No Content
==============

Le code de statut de réponse HTTP **`204 No Content`** indique que la requête a réussi mais que le client n'a pas besoin de quitter la page actuelle.

Généralement, ce code est renvoyé lorsque le résultat d'une requête `PUT` et qu'une ressource est mise à jour, sans modifier le contenu actuel de la page affichée à l'utilisateur (par exemple un éditeur de texte en ligne avec une fonctionnalité « Enregistrer et continuer à travailler »). Si la ressource est créée, c'est le code de statut `201 Created` qui sera renvoyé à la place. Si la page doit être actualisée avec une nouvelle page mise à jour, c'est le code de statut `200` qui doit être utilisé à la place.

Par défaut, une réponse 204 peut être mise en cache. Un en-tête `ETag` est inclus pour ce type de réponse.

Statut
------
```

204 No Content
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.204 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

### Notes de compatibilités

Bien que ce code de statut est censé décrire une réponse sans corps, les serveurs pourraient inclure des données dans le corps selon les en-têtes utilisés. Le protocole permet aux agents utilisateur d'avoir différentes façons de traiter de telles réponses (voir cette discussion).

Ceci est observable pour les connexions persistentes où un corps invalide pourrait inclure une réponse distincte correspondant à une requête ultérieure.

Apple Safari rejette ces données. Google Chrome et Microsoft Edge ignorent jusqu'à quatre octets qui précèderaient une réponse valide. Firefox tolère un kilo-octet de données invalides précédant une réponse valide.

Voir aussi
----------

* Les verbes utilisés pour les méthodes HTTP
503 Service Unavailable
=======================

Le code de réponse HTTP d'erreur serveur **`503 Service Unavailable`** indique que le serveur n'est pas prêt à traiter la requête.

Généralement, cela se produit car le serveur est éteint ou inaccessible pour cause de maintenance ou de surcharge. Cette réponse doit être utilisée pour indiquer un état temporaire et l'en-tête HTTP `Retry-After` (en-US) doit, si possible, indiquer le temps estimé avant la reprise du service.

**Note :** Avec cette erreur, il est préférable d'envoyer une page compréhensible pour l'utilisateur qui explique le problème.

Les en-têtes relatifs au cache qui sont envoyés avec cette réponse doivent être pris en compte, car un code de statut 503 indique un état temporaire et cette réponse ne doit généralement pas être mise en cache.

Statut
------
```

503 Service Unavailable
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.503 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Retry-After` (en-US)
* HTTP/1.1 : Définitions des codes de statut (en anglais)
405 Method Not Allowed
======================

Le code de statut de réponse HTTP **`405 Method Not Allowed`** indique que la méthode utilisée pour la requête est connue du serveur mais qu'elle n'est pas supportée par la ressource ciblée.

Le serveur doit générer un en-tête **`Allow`** en cas de réponse 405, contenant la liste des méthodes supportées par la ressource ciblée.

Statut
------
```

405 Method Not Allowed
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.405 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `Allow`
* HTTP/1.1 : Définitions des codes de statut (en anglais)
* Comment corriger l'erreur `405 Method Not Allowed`
* Résoudre l'erreur HTTP 405
302 Found
=========

Le code de statut de réponse de redirection **`302 Found`** indique que la ressource est temporairement déplacée vers l'URL contenue dans l'en-tête `Location`. Un navigateur redirige vers cette page, mais les moteurs de recherche ne mettent pas à jour leurs liens vers la ressource (en termes de référencement, cela indique que le flux de référencement n'est pas envoyé vers la nouvelle URL).

Même si la spécification impose que la méthode et le corps ne soient pas altérés lors d'une redirection, tous les agents utilisateurs ne s'y conforment pas et il est toujours possible de trouver des logiciels bogués sur ce point. Il est donc recommandé d'utiliser le code `302` uniquement comme réponse à une méthode `GET` ou `HEAD` et d'utiliser le code `307 Temporary Redirect` à la place puisque le changement de méthode est explicitement interdit dans ce cas.

Si vous souhaitez que la méthode utilisée soit changée en `GET`, vous pouvez utiliser `303 See Other` à la place. Ceci s'avère utile lorsqu'on souhaite donner une réponse à une méthode `PUT` qui n'est pas la ressource téléversée, mais plutôt un message de confirmation (par exemple, « Vous avez téléversé avec succès XYZ »).

Statut
------
```

302 Found
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.302 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `307 Temporary Redirect`, l'équivalent de ce code de statut, mais qui ne change jamais la méthode utilisée.
* `303 See Other`, une redirection temporaire qui change la méthode utilisée par `GET`.
* `301 Moved Permanently`, la redirection permanente.
507 Insufficient Storage
========================

Le code de réponse HTTP **`507 Insufficient Storage`** peut être donné dans le contexte du protocole WebDAV (voir RFC 4918).

Il indique que la méthode ne peut pas être traitée car le serveur ne peut pas stocker la représentation nécessaire pour accomplir la requête avec succès.

Statut
------
```

507 Insufficient Storage
```

Spécifications
--------------

| Specification |
| --- |
| RFC 4918 # section-11.5 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}
428 Precondition Required
=========================

Le code de statut de réponse HTTP **`428 Precondition Required`** indique que le serveur requiert que la requête soit conditionnelle.

Généralement, cela signifie qu'il **manque** un en-tête de précondition, comme `If-Match` (en-US).

Lorsqu'un en-tête de précondition **ne correspond pas** à l'état du serveur, la réponse doit être `412 Precondition Failed`.

Statut
------
```

428 Precondition Required
```

Spécifications
--------------

| Specification |
| --- |
| RFC 6585 # section-3 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* Les requêtes conditionnelles en HTTP
* `If-Match` (en-US)
* `412`
200 OK
======

Le code de statut de réponse HTTP **`200 OK`** indique la réussite d'une requête. Une réponse 200 peut être mise en cache par défaut.

La signification de la réussite dépend de la méthode de requête HTTP :

* `GET` : la ressource a été récupérée et est transmise dans le corps du message.
* `HEAD` : l'ensemble des en-têtes est présent dans la réponse, celle-ci n'a pas de corps.
* `POST` : la ressource qui décrit le résultat d'une action est transmise dans le corps du message.
* `TRACE` : le corps du message contient le message de requête reçu par le serveur.

La plupart du temps, le résultat d'une requête réussie avec la méthode `PUT` ou `DELETE` n'est pas `200` `OK` mais plutôt `204 No Content` (ou `201 Created` lorsque la ressource est envoyée pour la première fois).

Statut
------
```

200 OK
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.200 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* Les verbes utilisés pour les méthodes HTTP
401 Unauthorized
================

Le code de statut de réponse HTTP **`401 Unauthorized`** indique que la requête n'a pas été effectuée, car il manque des informations d'authentification valides pour la ressource visée.

Ce statut est envoyé avec un en-tête de réponse `WWW-Authenticate` qui décrit la méthode pour s'authentifier correctement.

Ce statut est similaire à `403` mais, dans ce cas, une authentification est possible pour accéder à la ressource.

Statut
------
```

401 Unauthorized
```

Exemple de réponse
------------------
```

HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.401 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* La gestion de l'authentification en HTTP
* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `403`, `407`
415 Unsupported Media Type
==========================

Le code de réponse d'erreur HTTP **`415 Unsupported Media Type`** indique que le serveur refuse la requête, car le format de la charge utile (*payload*) n'est pas pris en charge.

Le problème de format peut être causé par les valeurs des en-têtes `Content-Type` ou `Content-Encoding` dans la requête ou, plus directement, à cause de l'inspection des données.

Statut
------
```

415 Unsupported Media Type
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.415 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `Content-Type`
* `Content-Encoding`
* `Accept`
409 Conflict
============

Le code de statut de réponse **`409 Conflict`** indique que la requête entre en conflit avec l'état actuel du serveur.

Les conflits se produisent généralement en réponse à une requête `PUT`. Par exemple, vous pouvez obtenir une réponse 409 lorsque vous téléversez un fichier qui est plus vieux que celui déjà présent sur le serveur, ce qui entraine un conflit de contrôle de version.

Statut
------
```

409 Conflict
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.409 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `PUT`
411 Length Required
===================

Le code de réponse d'erreur HTTP **`411 Length Required`** indique que le serveur refuse d'accepter la requête si celle-ci ne contient pas d'en-tête `Content-Length`.

**Note :** Selon la spécification, lors de l'envoi de données en plusieurs fragments, l'en-tête `Content-Length` est absent et il est nécessaire d'ajouter la longueur du fragment courant au format hexadécimal. Pour plus de détails, se référer à la page sur l'en-tête `Transfer-Encoding` (en-US).

Statut
------
```

411 Length Required
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.411 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `Content-Length`
* `Transfer-Encoding` (en-US)
103 Early Hints
===============

Le code de statut de réponse **`103 Early Hints`** est principalement utilisé avec l'en-tête HTTP `Link` afin de permettre à l'application cliente de commencer le chargement des ressources tandis que le serveur prépare une réponse.

Syntaxe
-------
```

103 Early Hints
```

Spécifications
--------------

| Specification |
| --- |
| An HTTP Status Code for Indicating Hints # section-2 |
| HTML Standard # early-hints |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `Link`
414 URI Too Long
================

Le code de statut de réponse HTTP **`414 URI Too Long`** indique que l'URI demandée par le client est plus longue que ce que le serveur est disposé à interpréter.

Il existe quelques rares cas de figure pour lesquels cela peut se produire :

* Un client a mal converti une requête `POST` vers une requête `GET` qui contient de nombreuses informations,
* Un client est descendu dans une boucle de redirection (par exemple, un URI de redirection qui pointe vers un suffixe de lui-même),
* Un serveur est sous le coup d'une attaque par un client qui tente d'exploiter des failles de sécurité potentielles.
Statut
------
```

414 URI Too Long
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.414 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* URI
425 Too Early
=============

**Expérimental:** **Cette fonction est expérimentale**  
Puisque cette fonction est toujours en développement dans certains navigateurs, veuillez consulter le tableau de compatibilité pour les préfixes à utiliser selon les navigateurs.  
Il convient de noter qu'une fonctionnalité expérimentale peut voir sa syntaxe ou son comportement modifié dans le futur en fonction des évolutions de la spécification.

Le code de réponse d'erreur HTTP **`425 Too Early`** signifie que le serveur refuse la requête qui a été récemment répétée par exemple de peur d'une attaque par rejeu.

Statut
------
```

425 Too Early
```

Spécifications
--------------

| Specification |
| --- |
| Using Early Data in HTTP # status |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
408 Request Timeout
===================

Le code de statut de réponse HTTP **`408 Request Timeout`** indique que le serveur souhaiterait clôturer cette connexion inutilisée. Pour certains serveurs, ce code est parfois envoyé sur une connexion inactive sans qu'il y ait nécessairement eu de requête de la part du client.

Un serveur doit envoyer l'en-tête `Connection` avec la valeur `close` en réponse, puisque `408` implique que le serveur a décidé de fermer la connexion plutôt que de continuer à attendre.

Cette réponse est plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent le mécanisme HTTP de pré-connexion qui permet d'accélérer la navigation.

**Note :** Certains serveurs ferment purement et simplement la connexion, sans renvoyer ce message.

Statut
------
```

408 Request Timeout
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.408 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `Connection`
* `X-DNS-Prefetch-Control` (en-US)
410 Gone
========

Le code de statut de réponse HTTP **`410 Gone`** est une erreur côté client qui indique que l'accès à la ressource visée n'est plus disponible sur le serveur d'origine et que cet état est susceptible d'être définitif.

Si vous ne savez pas si cette absence est temporaire ou permanente, il est préférable de renvoyer un code de statut `404`.

**Note :** Par défaut, une réponse 410 peut être mise en cache.

Statut
------
```

410 Gone
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.410 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `404`
205 Reset Content
=================

Le code de statut de réponse HTTP **`205 Reset Content`** indique au client de réinitialiser la vue du document, par exemple afin de nettoyer le contenu d'un formulaire, réinitialiser l'état d'un canevas (`<canvas>`), ou pour mettre à jour l'interface utilisateur.

Statut
------
```

205 Reset Content
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.205 |

Compatibilité des navigateurs
-----------------------------

{{Compat}}Voir aussi
----------

* `204 No Content`
502 Bad Gateway
===============

Le code de réponse HTTP d'erreur serveur **`502 Bad Gateway`** indique que le serveur, agissant comme une passerelle ou un proxy, a reçu une réponse invalide depuis le serveur en amont.

**Note :** Une passerelle (*gateway*) peut faire référence à différents éléments en réseaux et une erreur 502 est habituellement quelque chose que vous ne pouvez pas corriger, mais qui nécessite une correction sur le serveur web ou le proxy par lequel vous passez pour y accéder.

Statut
------
```

502 Bad Gateway
```

Spécifications
--------------

| Specification |
| --- |
| HTTP Semantics # status.502 |

Compatibilité des navigateurs
-----------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Voir aussi
----------

* `504`
* HTTP/1.1 : Définitions des codes de statut (en anglais)