| Code de statut HTTP |
Signification du code |
| 100 |
Le client doit continuer à envoyer la requête. Cette réponse temporaire est utilisée pour notifier le client que sa partie de la requête a été reçue par le serveur et n'a pas encore été rejetée. Le client doit continuer à envoyer le reste de la requête ou, si la requête est déjà terminée, ignorer cette réponse. Le serveur doit envoyer une réponse finale au client une fois la requête terminée. |
| 101 |
Le serveur a compris la requête du client et communiquera au client d'adopter un protocole différent pour compléter cette requête par l'en-tête de message Upgrade. Après l'envoi de cette dernière ligne vide de réponse, le serveur passera aux protocoles définis dans l'en-tête Upgrade. De telles mesures ne devraient être prises que si la transition vers un nouveau protocole est bénéfique. Par exemple, passer à une nouvelle version HTTP serait plus avantageux que la version ancienne, ou passer à un protocole temps réel et synchronisé pour transférer des ressources bénéficiant de ces caractéristiques. |
| 102 |
Code de statut étendu par WebDAV (RFC 2518), représentant que le traitement continuera d'être exécuté. |
| 200 |
La requête a été réussie, et les en-têtes de réponse ou le corps de données souhaités par la requête seront renvoyés avec cette réponse. |
| 201 |
La requête a été réalisée, et une nouvelle ressource a été créée conformément aux besoins de la requête, et son URI a été retournée dans l'en-tête Location. Si la ressource requise ne peut pas être créée immédiatement, le code '202 Accepted' doit être renvoyé. |
| 202 |
Le serveur a accepté la requête mais ne l'a pas encore traitée. Comme elle peut être rejetée, cette requête peut ou ne peut pas être exécutée. Dans le cas d'opérations asynchrones, il n'est pas plus pratique que d'envoyer ce code de statut. La réponse renvoyant le code 202 doit contenir dans l'entité renvoyée des indicateurs d'informations sur l'état de traitement actuel, ainsi que des pointeurs vers un moniteur de statut ou une prédiction d'état, afin que l'utilisateur puisse estimer si l'opération a été complétée. |
| 203 |
Le serveur a traité la requête avec succès, mais les métadonnées de l'entité renvoyée ne sont pas un ensemble validé d'origine de celle-ci, mais proviennent d'une copie locale ou d'un tiers. Les informations actuelles peuvent être un sous-ensemble ou un sur-ensemble de l'original. Par exemple, les métadonnées de la ressource peuvent amener le serveur d'origine à connaître des informations supplémentaires. Utiliser ce code de statut n'est pas obligatoire, et il est approprié uniquement lorsque la réponse, ne pas utiliser ce code, serait 200 OK. |
| 204 |
Le serveur a réussi à traiter la requête, mais il n'est pas nécessaire de retourner le corps d'une entité, et souhaite renvoyer des métadonnées mises à jour. La réponse peut éventuellement retourner de nouvelles métadonnées ou des informations mises à jour sous l'idée d'un en-tête d'entité. Si de ces en-têtes existent, ils doivent correspondre à la variable demandée. Si le client est un navigateur, son navigateur doit conserver la page qui a envoyé la requête, sans produire de changement dans la vue du document, même si de nouvelles ou des informations mises à jour doivent normalement être appliquées à la vue active du navigateur pour le document. Étant donné que les réponses 204 sont interdites de contenir un corps de message, elles se terminent donc toujours par la première ligne vide suivant les en-têtes de message. |
| 205 |
Le serveur a réussi à traiter la requête et n'a pas renvoyé de contenu. Cependant, contrairement à la réponse 204, la réponse renvoyant ce code exige du demandeur qu'il réinitialise la vue du document. Cette réponse est essentiellement utilisée pour réinitialiser immédiatement le formulaire après réception des entrées de l'utilisateur, afin que l'utilisateur puisse commencer facilement une nouvelle entrée. Comme pour la réponse 204, cette réponse est également interdite de contenir tout corps de message et se termine par la première ligne vide après les en-têtes de message. |
| 206 |
Le serveur a réussi à traiter une partie de la requête GET. Des outils de téléchargement HTTP tels que FlashGet ou Thunder utilisent ce type de réponse pour implémenter la reprise des téléchargements ou diviser un grand document en plusieurs sections pour le téléchargement simultané. La requête doit contenir un en-tête Range pour indiquer au client la plage de contenu souhaitée, et peut éventuellement contenir If-Range comme condition de requête. La réponse doit contenir les en-têtes suivants : Content-Range pour indiquer la plage du contenu renvoyé dans cette réponse ; si Content-Type est multipart/byteranges pour les téléchargements en plusieurs segments, chaque segment multipart doit aussi contenir un en-tête Content-Range pour indiquer la plage du contenu de ce segment. Si la réponse contient Content-Length, sa valeur doit correspondre au nombre réel d'octets de la plage de contenu renvoyée. Date ETag et/ou Content-Location, si la même requête devrait renvoyer 200. Expires, Cache-Control, et/ou Vary, si leurs valeurs pourraient différer de celles d'autres réponses correspondant aux mêmes variables. Si cette réponse de requête utilisez If-Range, alors cette réponse ne devrait pas contenir d'autres en-têtes d'entités ; en revanche, si cette réponse a été validée avec If-Range de manière faible, alors cette réponse prohibe de contenir d'autres en-têtes d'entités ; cela évite l'incohérence entre le contenu de l'entité mis en cache et les en-têtes d'entités mis à jour. Sinon, cette réponse devrait contenir tous les en-têtes d'entité qui devraient être renvoyés dans la réponse 200. Si les en-têtes ETag ou Last-Modified ne correspondent pas précisément, alors le cache client devrait interdire la combinaison du contenu renvoyé par cette réponse avec tout contenu précédemment mis en cache. |
| 207 |
Code de statut étendu par WebDAV (RFC 2518), représentant que le corps suivant sera un message XML, et peut contenir une série de codes de réponse indépendants en fonction du nombre de sous-requêtes précédentes. |
| 300 |
La ressource demandée dispose d'un ensemble de réponses sélectionnables, chacune ayant sa propre adresse et des informations marchandisées par le serveur. L’utilisateur ou le navigateur peut choisir une adresse préférée pour rediriger la demande. À moins qu'il s'agisse d'une requête HEAD, cette réponse devrait inclure un corps de réponse listant les attributs de la ressource et adresses, afin que l'utilisateur ou le navigateur puisse sélectionner l'adresse de redirection la plus appropriée. Le format de ce corps est déterminé par le format défini par l'en-tête Content-Type. Le navigateur peut automatiquement faire le choix le plus approprié en fonction du format de réponse et de ses propres capacités. Bien sûr, la norme RFC 2616 ne spécifie pas comment faire ce choix automatique. Si le serveur a un choix de retour préféré, cette URI de retour devrait être précisée dans l'en-tête Location; Le navigateur pourrait considérer cette valeur Location comme l'adresse de redirection automatique. De plus, à moins d'indications supplémentaires, cette réponse est également mise en cache. |
| 301 |
La ressource demandée a été déplacée de façon permanente à un nouvel emplacement, et toutes les références futures à cette ressource devraient utiliser l'un des URI renvoyés par cette réponse. Si possible, les clients ayant des fonctionnalités de modification de lien devraient automatiquement modifier l'adresse demandée à celle renvoyée par le serveur. À moins qu'il n'y ait des spécifications supplémentaires, cette réponse est également mise en cache. Le nouvel URI permanent devrait être renvoyé dans l'en-tête Location. À moins qu'il s'agisse d'une requête HEAD, le corps de la réponse devrait contenir un lien hypertexte vers la nouvelle URI et une brève description. Si ce n'est pas une requête GET ou HEAD, le navigateur interdit la redirection automatique, à moins que cela soit confirmé par l'utilisateur, car les conditions de la requête peuvent changer. Note : Pour certains navigateurs utilisant le protocole HTTP/1.0, lorsqu'une requête POST a reçu une réponse 301, le prochain appel de redirection deviendra une méthode GET. |
| 302 |
La ressource demandée répond temporairement sous un URI différent. Étant donné que cette redirection est temporaire, le client doit continuer à envoyer des requêtes à l'adresse d'origine. Cette réponse n'est mise en cache que si spécifiée dans Cache-Control ou Expires. La nouvelle URI temporaire devrait être renvoyée dans l'en-tête Location. À moins qu'il s'agisse d'une requête HEAD, le corps de la réponse devrait contenir un lien hypertexte vers la nouvelle URI et une brève description. Si ce n'est pas une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf si cela est confirmé par l'utilisateur, car les conditions de la requête peuvent changer. Remarque : Bien que les normes RFC 1945 et RFC 2068 n'autorisent pas le client à changer la méthode de la requête lors de la redirection, de nombreux navigateurs existants traitent la réponse 302 comme une réponse 303 et utilisent la méthode GET pour accéder à l'URI spécifié dans l'en-tête Location, ignorant la méthode de requête d'origine. Les codes de statut 303 et 307 ont été ajoutés pour clarifier la réaction que le serveur attend du client. |
| 303 |
La réponse à la requête actuelle peut être trouvée à un autre URI, et le client devrait accéder à ce contenu en utilisant la méthode GET. Cette méthode existe principalement pour permettre à la sortie de requêtes POST activées par un script d'être redirigée vers une nouvelle ressource. Ce nouvel URI n'est pas une référence alternative à la ressource d'origine. De plus, la réponse 303 interdit la mise en cache. Bien entendu, la seconde requête (redirection) peut être mise en cache. La nouvelle URI doit être renvoyée dans l'en-tête Location. À moins qu'il s'agisse d'une requête HEAD, le corps de la réponse doit contenir un lien vers la nouvelle URI et une brève description. Remarque : De nombreux navigateurs antérieurs à HTTP/1.1 ne comprennent pas correctement le code d'état 303. Si vous devez considérer l'interaction avec ces navigateurs, le code d'état 302 devrait faire l'affaire, car c'est ainsi que la plupart des navigateurs traitent la réponse 302. |
| 304 |
Si le client a envoyé une requête GET conditionnelle et que la requête a été acceptée, et que le contenu du document (depuis la dernière visite ou en fonction des conditions de la requête) n'a pas changé, le serveur devrait renvoyer ce code de statut. Les réponses 304 sont interdites d'inclure un corps de message, et se terminent donc toujours par la première ligne vide après les en-têtes de message. Cette réponse doit contenir les informations d'en-tête suivantes : Date, à moins que ce serveur n'ait pas d'horloge. Si le serveur sans horloge respecte également ces règles, alors les proxy et clients peuvent ajouter leur champ Date aux en-têtes de réponse reçus (comme spécifié dans la RFC 2068), et le mécanisme de mise en cache fonctionnera normalement. ETag et/ou Content-Location, si la même requête devrait renvoyer 200. Expires, Cache-Control, et/ou Vary, si leurs valeurs pourraient différer de celles des autres réponses relatives aux mêmes variables. Si cette réponse de requête utilise une validation de cache stricte, cette réponse ne devrait pas contenir d'autres en-têtes d'entités; sinon, lorsque la requête GET conditionnelle utilise une validation de cache faible, cette réponse n'est pas autorisée à contenir d'autres en-têtes d'entités; cela évite l'incohérence entre les contenus des entités mis en cache et les en-têtes d'entités mis à jour. Si une réponse 304 a indiqué qu'une certaine entité n'était pas mise en cache, alors le système de cache doit ignorer cette réponse, et renvoyer une nouvelle requête sans conditions. Si vous recevez une réponse 304 demandant la mise à jour d'une certaine entrée de cache, alors le système de cache doit mettre à jour l'ensemble de l'entrée pour refléter toutes les valeurs des champs mis à jour dans la réponse. |
| 305 |
La ressource demandée doit être accédée via le proxy spécifié. L'URI de ce proxy sera donnée dans l'en-tête Location, et le destinataire doit renvoyer une requête séparée pour accéder à la ressource correspondante via ce proxy. Seul le serveur d'origine peut émettre une réponse 305. Note : La RFC 2068 ne précise pas que la réponse 305 est nécessaire pour rediriger une requête séparée, et seule le serveur d'origine peuvent établir cette réponse. Ignorer ces restrictions pourrait conduire à des conséquences de sécurité graves. |
| 306 |
Dans la dernière spécification, le code de statut 306 n'est plus utilisé. |
| 307 |
La ressource demandée répond temporairement sous un URI différent. Étant donné que cette redirection est temporaire, le client doit continuer à envoyer des requêtes à l'adresse d'origine. Cette réponse n'est mise en cache que si spécifiée dans Cache-Control ou Expires. La nouvelle URI temporaire devrait être renvoyée dans l'en-tête Location. À moins qu'il ne s'agisse d'une requête HEAD, le corps de la réponse devrait contenir un lien hypertexte vers la nouvelle URI et une brève description. Étant donné que certains navigateurs ne peuvent pas reconnaître la réponse 307, des informations supplémentaires doivent être ajoutées afin que l'utilisateur puisse comprendre et soumettre une requête d'accès à la nouvelle URI. Si ce n'est pas une requête GET ou HEAD, le navigateur interdit la redirection automatique, sauf si cela est confirmé par l'utilisateur, car les conditions de la requête peuvent changer. |
| 400 |
1. Sémantique erronée, la requête actuelle ne peut pas être comprise par le serveur. À moins d'une modification, le client ne devrait pas soumettre à nouveau cette requête. 2. Paramètres de la requête erronés. |
| 401 |
La requête actuelle nécessite une authentification de l'utilisateur. Cette réponse doit inclure une information d'en-tête WWW-Authenticate appropriée pour demander les informations de l'utilisateur. Le client peut renvoyer à nouveau une requête contenant des informations d'autorisation appropriées. Si la requête actuelle inclut déjà des attestations d'autorisation, alors la réponse 401 représente un refus par le serveur d'authentifier ces attestations. Si la réponse 401 contient la même demande d'authentification que la réponse précédente, et que le navigateur a tenté l'authentification au moins une fois, alors il doit afficher à l'utilisateur les informations d'entité incluses dans la réponse, car ces informations peuvent contenir des diagnostics utiles. Voir RFC 2617. |
| 402 |
Ce code de statut est réservé pour des besoins potentiels futurs. |
| 403 |
Le serveur a compris la requête, mais refuse de l'exécuter. Contrairement à la réponse 401, l'authentification ne peut rien aider, et cette requête ne devrait pas être soumise à nouveau. Si ce n'est pas une requête HEAD, et que le serveur souhaite expliquer pourquoi la requête ne peut pas être exécutée, il devrait décrire les raisons du refus dans l'entité. Bien entendu, le serveur pourrait également renvoyer une réponse 404 s'il ne souhaite pas que le client obtienne des informations. |
| 404 |
La requête a échoué, et la ressource souhaitée n'a pas été trouvée sur le serveur. Il n'y a pas d'informations disponibles pour indiquer si cette situation est temporaire ou permanente. Si le serveur connaît la situation, il devrait utiliser le code d'état 410 pour indiquer qu'une ancienne ressource est devenue définitivement indisponible en raison de certains problèmes de configuration internes, et qu'il n'y a pas d'adresse de redirection. Le code 404 est largement utilisé lorsque le serveur ne souhaite pas révéler la raison pour laquelle la requête a été refusée ou lorsque aucune autre réponse appropriée n'est disponible. |
| 405 |
La méthode de requête spécifiée dans la ligne de requête ne peut pas être utilisée pour accéder à la ressource demandée. Cette réponse doit renvoyer une information d'en-tête Allow indiquant la liste des méthodes de requête actuellement acceptées par cette ressource. Étant donné que les méthodes PUT et DELETE effectueront des opérations d'écriture sur la ressource du serveur, la plupart des serveurs web ne les prennent pas en charge ou ne les autorisent pas dans les configurations par défaut, et renverront donc une erreur 405 pour de telles requêtes. |
| 406 |
Le contenu de la ressource demandée ne peut pas satisfaire les conditions spécifiées dans les en-têtes de la requête, donc la réponse d'entité ne peut pas être générée. À moins qu'il ne s'agisse d'une requête HEAD, cette réponse devrait renvoyer un corps contenant une liste d'attributs et d'adresses permettant à l'utilisateur ou au navigateur de choisir la meilleure option. Le format de l'entité est déterminé par le type de média défini dans l'en-tête Content-Type. Le navigateur peut faire le meilleur choix possible en fonction du format et de ses capacités. Toutefois, la norme ne définit aucune norme pour faire ce choix automatique. |
| 407 |
Similaire à la réponse 401, sauf que le client doit s'authentifier auprès du serveur proxy. Le serveur proxy doit renvoyer une information Proxy-Authenticate pour demander l'authentification. Le client peut renvoyer une information d'en-tête Proxy-Authorization pour l'authentification. Voir RFC 2617. |
| 408 |
La requête a expiré. Le client n'a pas terminé l'envoi d'une requête dans le temps prévu par le serveur. Le client peut soumettre cette requête à nouveau à tout moment sans modification. |
| 409 |
En raison d'un conflit avec l'état actuel de la ressource demandée, la requête ne peut pas être complétée. Ce code ne peut être utilisé que dans le cas suivant : l'utilisateur doit pouvoir résoudre le conflit et soumettre une nouvelle requête. La réponse doit contenir suffisamment d'informations pour que l'utilisateur identifie la source du conflit. Les conflits se produisent généralement dans le traitement des requêtes PUT. Par exemple, dans un environnement avec vérification de version, les informations de version jointes à une requête de modification PUT pour une ressource spécifique pourraient être en conflit avec une autre (tierce) requête, et dans ce cas, le serveur devrait retourner une erreur 409, indiquant que la requête ne peut pas être complétée. À ce stade, l'entité de la réponse pourrait contenir une comparaison des différences entre les deux versions en conflit pour permettre à l'utilisateur de soumettre un nouveau version à fusionner. |
| 410 |
La ressource demandée n'est plus disponible sur le serveur, et il n'y a aucune adresse de redirection connue. Cette situation doit être considérée comme permanente. Le client ayant des fonctionnalités de modification de lien devrait supprimer toutes les références à cette adresse après avoir obtenu la permission de l'utilisateur. Si le serveur ne sait pas ou n'est pas en mesure de déterminer si cette situation est permanente, alors il devrait utiliser le code d'état 404. À moins d'indications supplémentaires, cette réponse est mise en cache. L'objectif de la réponse 410 est d'aider les administrateurs à maintenir le site, en informant les utilisateurs que la ressource est devenue indisponible, et en souhaitant que toutes les connexions à distance à cette ressource soient supprimées. De tels événements se produisent souvent dans le cadre de services à durée limitée ou de services à valeur ajoutée. De même, la réponse 410 est utilisée pour informer les clients que, sur le site actuel, une ressource qui appartenait à une personne n'est plus disponible. Bien sûr, la décision de marquer toutes les ressources devenues définitivement indisponibles comme '410 Gone', ainsi que la période pendant laquelle cette marque doit être maintenue, revient entièrement au propriétaire du serveur. |
| 411 |
Le serveur refuse d'accepter la requête sans avoir une définition d'en-tête Content-Length. Après avoir ajouté un en-tête Content-Length valide indiquant la longueur du corps de message de la requête, le client doit soumettre à nouveau cette requête. |
| 412 |
Lorsque le serveur vérifie les conditions préalables spécifiées dans les champs d'en-tête de la requête et échoue à satisfaire l'une ou l'autre de ces conditions. Ce code de statut permet au client de définir des conditions préalables dans les informations de métadonnées de la requête (données des champs d'en-tête de la requête) lors de l'accès à la ressource, afin d'éviter que cette méthode de requête s'applique à une ressource autre que celle qu'il souhaite. |
| 413 |
Le serveur refuse de traiter la requête actuelle car l'entité de données soumise dépasse la taille que le serveur est prêt ou capable de traiter. Dans ce cas, le serveur peut fermer la connexion pour éviter que le client n'envoie cette requête. Si cette situation est temporaire, le serveur devrait renvoyer un en-tête Retry-After pour informer le client du moment où il peut réessayer. |
| 414 |
La longueur de l'URI demandée dépasse la longueur que le serveur peut interpréter, donc le serveur refuse d'apporter un service pour cette requête. Cela est relativement rare et se produit principalement dans les cas suivants : des soumissions de formulaire qui auraient dû utiliser la méthode POST se transforment en méthode GET, entraînant une chaîne de requête (Query String) trop longue. URI de redirection "trou noir", où chaque redirection utilise l'ancienne URI comme part de la nouvelle URI, ce qui provoque une longueur excessive après plusieurs redirections. Un client tentant d'exploiter une vulnérabilité de sécurité dans le serveur. Ce type de serveur utilise une lecture de tampon de longueur fixe et la portée de l'URI demandé peut provoquer un débordement de tampon, ce qui permettra l'exécution de code arbitraire. Les serveurs sans pareilles vulnérabilités devraient retourner le code d'état 414. |
| 415 |
Pour la méthode actuelle de la requête et la ressource demandée, l'entité soumise dans la requête n’est pas au format pris en charge par le serveur, entraînant ainsi le rejet de la requête. |
| 416 |
Si la requête inclut un en-tête de requête Range, et si toute plage spécifiée dans l'en-tête Range ne chevauche pas la plage disponible pour la ressource actuelle, et qu'aucun en-tête If-Range n’est défini dans la demande, le serveur devrait renvoyer le code d'état 416. Si la plage utilisée est en octets, cela signifie que les premiers octets spécifiés dans la plage demandée dépassent la longueur de la ressource actuelle. Le serveur doit renvoyer simultanément le code d'état 416 avec un en-tête Content-Range pour indiquer la longueur actuelle de la ressource. Cette réponse est également interdite d'utiliser multipart/byteranges comme son Content-Type. |
| 417 |
Le contenu attendu défini dans l'en-tête Expect de la requête ne peut pas être satisfait par le serveur ou le serveur est un proxy qui dispose de preuves évidentes que le contenu Expect ne peut pas être satisfait au prochain nœud dans le chemin. |
| 421 |
Le nombre de connexions du client à partir de l'adresse IP actuelle dépasse la limite maximale autorisée par le serveur. Généralement, l'adresse IP ici fait référence à l'adresse du client vue par le serveur (comme l'adresse passerelle ou le serveur proxy de l'utilisateur). Dans ce cas, le calcul du nombre de connexions peut impliquer plus d'un utilisateur final. |
| 422 |
Le format de la requête est correct, mais un problème sémantique l'empêche d'être servi. (RFC 4918 WebDAV) 423 Locked La ressource actuelle est verrouillée. (RFC 4918 WebDAV) |
| 424 |
La requête a échoué à cause d'une erreur survenue lors d'une requête antérieure, par exemple PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Défini dans l'ébauche des Collections Avancées WebDav, mais non mentionné dans le "Protocole des ensembles ordonnés WebDAV" (RFC 3658). |
| 426 |
Le client doit passer à TLS/1.0. (RFC 2817) |
| 449 |
Élargi par Microsoft, signifie que la requête devrait être réessayée après exécution des opérations appropriées. |
| 500 |
Le serveur a rencontré une condition inattendue qui a empêché de répondre à la requête. En général, ce problème se produit lorsque le code du serveur est défectueux. |
| 501 |
Le serveur ne prend pas en charge une fonctionnalité requise par la requête actuelle. Lorsque le serveur ne reconnaît pas la méthode de requête et ne peut pas traiter les demandes concernant une ressource. |
| 502 |
Le serveur, agissant en tant que passerelle ou proxy, a reçu une réponse invalide d'un serveur en amont lors de la tentative d'exécution de la requête. |
| 503 |
Le serveur est actuellement incapable de traiter la requête en raison d'une maintenance temporaire ou d'une surcharge. Cette situation est temporaire et devrait se résoudre après un certain temps. Si un délai peut être prévu, la réponse peut inclure un en-tête Retry-After indiquant ce délai. Si aucune information sur Retry-After n'est fournie, alors le client devrait traiter cela comme si c'était une réponse 500. Remarque : L'existence du code d'état 503 ne signifie pas que le serveur doit l'utiliser lors d'une surcharge. Certains serveurs peuvent simplement choisir de refuser les connexions du client. |
| 504 |
Le serveur, agissant en tant que passerelle ou proxy, n'a pas reçu de réponse en temps voulu d'un serveur en amont (serveur désigné par l'URI, tel que HTTP, FTP, LDAP) ou de serveurs auxiliaires (tel que DNS). Note : certains serveurs proxy retournent une erreur 400 ou 500 lors d'un délai de requête DNS. |
| 505 |
Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version HTTP utilisée dans la requête. Cela implique que le serveur ne peut ou ne veut pas utiliser la même version que le client. La réponse doit inclure une entité décrivant pourquoi la version n'est pas prise en charge et quelles versions le serveur prend en charge. |
| 506 |
Élargi par "The Transparent Content Negotiation Protocol" (RFC 2295), indique que le serveur a une erreur de configuration interne : la ressource demandée pour la négociation est configurée pour s'utiliser elle-même dans la négociation de contenu, de sorte que ce n’est pas un point central dans le traitement de la négociation. |
| 507 |
Le serveur est incapable de stocker la représentation nécessaire pour compléter la requête. Cette situation est considérée comme temporaire. WebDAV (RFC 4918) |
| 509 |
Le serveur a atteint sa limite de bande passante. Ce n'est pas un code d'état officiel, mais il est encore largement utilisé. |
| 510 |
La politique requise pour obtenir la ressource n'a pas été satisfaite. (RFC 2774) |