http (Hypertext Transfer Protocol) est un protocole de couche application sans état basé sur le mode requête et réponse, souvent basé sur la méthode de connexion TCP. Cet article parle des connaissances sur le protocole http que les développeurs front-end doivent connaître. Les amis qui souhaitent faire du front-end ou qui travaillent actuellement sur le front-end doivent le connaître.
1. Concept
http (Hypertext Transfer Protocol) est un modèle de requête et de réponse. basé sur des protocoles de couche application, sans état , souvent basés sur la méthode de connexion TCP. La version HTTP 1.1 fournit un mécanisme de connexion continue. La grande majorité du développement Web est construite sur des applications Web HTTP basées sur le protocole.
2. Développement
Version 0.9 (supporte uniquement get) - 1.0 - 1.1 - 2.0 (en cours de développement)
La version 0.9 ne peut être considérée que comme une version d'essai et ne sera pas introduite. Parlez principalement de la différence entre 1.0 et 1.1.
2.1 Connexion persistante et connexion non persistante
La version 1.0 prend en charge la connexion non persistante, ce qui signifie qu'elle passe le protocole TCP (http est un protocole de couche application basé sur TCP) poignée de main à trois voies Une fois la connexion établie, le serveur ne peut envoyer qu'un seul objet au navigateur, puis le lien est déconnecté si la page Web contient d'autres objets en ligne, tels que des images, des fichiers js, des fichiers css, etc. etc., plusieurs liens doivent être établis, ce qui implique la surcharge liée à l'établissement/déconnexion plusieurs fois. La version 1.1 prend en charge les liens continus. Une fois la connexion établie, plusieurs objets peuvent être envoyés. Par conséquent, en théorie, la version 1.1 est plus économe en ressources et plus rapide que la 1.0. Cependant, certains internautes disent que la 1.0 est plus rapide, ce qui est inacceptable. il.
2.2 Domaine hôte
Le champ d'en-tête Host précise l'hôte Internet et le numéro de port de la ressource demandée, et doit indiquer l'emplacement du serveur ou de la passerelle d'origine de l'URL demandée. Les requêtes HTTP/1.1 doivent inclure le champ d'en-tête de l'hôte, sinon le système renverra un code d'état 400. Ce champ semble inutile, peut-être pour augmenter la vitesse. Après tout, spécifier directement HOST permet de trouver l'hôte correspondant plus rapidement. Si l'hôte n'existe pas, il peut également être découvert plus rapidement.
2.3 Optimisation de la bande passante
La version 1.1 prend en charge la demande de ressources partielle et vous ne pouvez demander qu'une partie de la ressource. Dans le même temps, la version 1.1 prend en charge le code d'état 100. Lorsque l'entité de requête est grande, vous pouvez d'abord envoyer le champ d'en-tête avec le code d'état 100 pour confirmer si le serveur répond à la requête. S'il peut répondre, l'entité de requête. est renvoyé, de sorte qu'à un certain moment, économisez la bande passante dans certaines situations qui ne répondent pas.
Processus spécifique : Client - envoie un en-tête de requête avec un code d'état 100 - le serveur confirme s'il peut répondre. Sinon, renvoie le code d'état correspondant (par exemple 401, non authentifié). puis renvoie le code d'état 100 - le client confirme s'il doit continuer à envoyer la demande en fonction du code d'état de retour.
2.4 Méthodes de requête et codes d'état
HTTP1.1 ajoute OPTIONS, PUT, DELETE, TRACE, CONNECT et d'autres méthodes de requête
Seulement 16 sont définies dans l'état HTTP/1.0 les codes de réponse ne sont pas suffisamment spécifiques pour les erreurs ou les avertissements. HTTP/1.1 a introduit un champ d'en-tête Warning pour ajouter une description des informations d'erreur ou d'avertissement.
24 nouveaux codes de réponse d'état ont été ajoutés dans HTTP/1.1. Par exemple, 409 (Conflit) indique que la ressource demandée est en conflit avec l'état actuel de la ressource ; Le serveur est définitivement supprimé.
3. Processus de communication http
(1) Interrogez DNS en fonction de l'URL, recherchez le serveur Web et établissez une connexion TCP avec il (accord de couche inférieure http).
(2) Ensuite, le navigateur Web envoie une requête au serveur.
Les requêtes incluent généralement : | Méthode de requête uri Numéro de version http | En-tête de la requête | Exemple de texte :
GET /hello.jpg HTTP/1.1
Accepter :image/gif.image/jpeg
Accepter-Langue : zh-cn
Connexion : Keep-Alive
Hôte : 127.0.0.1
Agent utilisateur : Mozila/4.0 (compatible ; MSIE5.01; Windows NT5.0)
Accepter l'encodage : gzip, dégonfler
(3) Réponse du serveur Web. Le package de réponse comprend généralement : |Description du code d'état de la version du protocole|En-tête de réponse|Texte de la réponse
HTTP/1.1 200 OK
Serveur : Apache Tomcat/5.0 .12
Date : lundi 6 octobre 2017 13:23:42 GMT
Longueur du contenu : 188
4. Champ d'en-tête http
Cette partie du contenu est trop détaillée et est répertoriée directement dans le tableau.
En-tête de la requête :
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
En-tête de réponse :
| En-tête | Explication | Exemple | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Accept-Ranges | Indique si le serveur prend en charge la demande de plage spécifiée et quel type Requête fragmentée | Plages d'acceptation : octets | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Âge | Durée estimée en secondes entre le serveur d'origine et la formation du cache proxy Nombre, non -négatif) | Âge : 12 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Autoriser | Un comportement de requête valide pour une certaine ressource réseau, si elle n'est pas autorisée Renvoie 405 | Autoriser : GET, HEAD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Cache-Control | Dites à tous les mécanismes de mise en cache s'ils peuvent être mis en cache et de quel type | Cache-Control : no-cache | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Encoding | Le type d'encodage de compression de contenu renvoyé pris en charge par le serveur Web. | Content-Encoding : gzip | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Language | La langue du corps de la réponse | Contenu -Langue : en,zh | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Length | La longueur du corps de la réponse | Content-Length : 348 td> tr> | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Location | Demander une adresse alternative pour la ressource | Content-Location : /index.htm | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-MD5 | Renvoie la valeur de contrôle MD5 de la ressource | Content-MD5 : Q2hlY2sgSW50ZWdyaXR5IQ== | La position en octets de cette partie dans l'ensemble du corps de retour | Content-Range : octets 21010-47021/47022 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Content-Type | Renvoyer le type MIME du contenu | Content-Type : text/html; tr> | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Date | L'heure à laquelle le message du serveur d'origine a été envoyé | Date : mar. 15 novembre 2010 08:12:31 GMT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ETag | La valeur actuelle de la balise d'entité de la variable de requête | ETag : "737060cd8c284d8af7ad3082f209582d" | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Expire | Date et heure d'expiration de la réponse | Expire : jeu. 1 décembre 2010 16:00:00 GMT | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Dernière modification | L'heure de la dernière modification de la ressource demandée | Dernière modification : mar 15 novembre 2010 12:45:26 GMT | Emplacement | Utilisé pour rediriger le destinataire vers l'emplacement de l'URL non demandée pour compléter la demande ou identifier une nouvelle ressource | Emplacement : http://www .zcmhi.com/archives/94.html | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Pragma | Contient des instructions spécifiques à l'implémentation qui peuvent être appliquées à n'importe quel récepteur dans la chaîne de réponse td> | Pragma : no-cache | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Proxy-Authenticate | Il indique le schéma d'authentification et les paramètres sur cette URL qui peuvent être appliqués au proxy | Proxy-Authentifier : Basique | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| actualiser | Appliquer pour rediriger ou une nouvelle ressource est créée, rediriger après 5 secondes ( proposé par Netscape, supporté par la plupart des navigateurs) |
Refresh : url=http : //www.zcmhi.com/archives /94.html |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Réessayer après | Si l'entité est temporairement indisponible, avertissez le client pour réessayer après le délai spécifié | Réessayer après : 120 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Serveur | Nom du logiciel du serveur Web | Serveur : Apache/1.3.27 (Unix) (Red-Hat/Linux)||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Set-Cookie | Définir le cookie HTTP | Set-Cookie : UserID=JohnDoe ; Max-Age=3600 ; Version=1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Trailer | Indique que le champ d'en-tête existe au niveau fin de l'encodage de transfert fragmenté | Trailer : Max-Forwards | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Transfer-Encoding | Encodage de transfert de fichiers | Transfer-Encoding:chunked||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Vary | Indique au proxy en aval s'il doit utiliser une réponse ou une demande en cache du serveur d'origine | Vary : *||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Via | Informe le proxy où la réponse du client est envoyée | Via : 1.0 fred, 1.1 nulle part .com (Apache/1.1) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Avertissement | Avertissement concernant d'éventuels problèmes avec les entités | Avertissement : 199 Avertissement divers | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| WWW-Authenticate | Indique le schéma d'autorisation que l'entité requérante client doit utiliser | WWW-Authenticate : Basic | tr>
5. Méthode de requête http
Requête GET pour obtenir la ressource identifiée par Request-URI
POST dans la ressource identifiée par Request -URI Ajouter de nouvelles données après la ressource
HEAD Requête pour obtenir l'en-tête du message de réponse de la ressource identifiée par Request-URI
PUT Demander au serveur de stocker une ressource et utiliser Request-URI comme identifiant
DELETE Demander au serveur de supprimer Requête - La ressource identifiée par l'URI
TRACE Demande au serveur de renvoyer les informations de la demande reçue, principalement utilisées pour les tests ou le diagnostic
CONNECT Réservé pour une utilisation future
OPTIONS Demande d'interrogation du performances du serveur, ou options de requête et exigences liées à la ressource
6 Code d'état
Réponse La première ligne de. le message est appelé ligne d'état, qui comprend le numéro de version du protocole HTTP, le code d'état, le message d'état se compose de trois parties.
Le code d'état est utilisé pour indiquer au client HTTP si le serveur HTTP a généré la réponse attendue.
HTTP/1.1 définit 5 types de codes d'état. Le code d'état est composé de trois chiffres. Un nombre définit la catégorie de la réponse
Message d'invite 1XX - indique que la demande a été reçue avec succès et continue d'être traitée, indiquant que les données doivent continuer à être reçues pour terminer la demande.
2XX Success - Indique que la demande a été reçue, comprise et acceptée avec succès
3XX Redirect - Un traitement ultérieur doit être effectué pour terminer la demande
4XX Client Error - Requête Il y a une erreur de syntaxe ou la requête ne peut pas être mise en œuvre
5XX Erreur côté serveur - Le serveur n'a pas réussi à mettre en œuvre une demande légale
Liste des codes d'état
Tableau 1 ( bref tableau d'introduction, introduction introduction Il est concis et clair Il est recommandé de vérifier d'abord ce tableau. Si vous ne comprenez pas, consultez le tableau ci-dessous 2)
.| Code de statut | Code de statut Nom anglais | Description en chinois |
|---|---|---|
| Codes d'état commençant par 1 | ||
| 100 | Continuer | continuer. Le client doit poursuivre sa demande |
| 101 | Switching Protocols | Switching protocols. Le serveur change de protocole en fonction de la demande du client. Vous ne pouvez passer qu'à un protocole plus avancé, par exemple passer à une nouvelle version du protocole HTTP |
| Code d'état commençant par 2 | ||
| 200 | OK | La demande a abouti. Généralement utilisé pour les requêtes GET et POST |
| 201 | Créé | a été créé. Demande et création réussie d'une nouvelle ressource |
| 202 | Accepté | Accepté. La demande a été acceptée mais n'a pas été traitée |
| 203 | Informations non autorisées | Informations non autorisées. La demande a abouti. Mais les méta-informations renvoyées ne sont pas dans le serveur d'origine, mais une copie |
| 204 | Aucun contenu | Aucun contenu. Le serveur a traité avec succès, mais aucun contenu n'a été renvoyé. Garantit que le navigateur continue d'afficher le document actuel sans mettre à jour la page Web |
| 205 | Réinitialiser le contenu | Réinitialiser le contenu. Le traitement du serveur réussit et le terminal utilisateur (par exemple le navigateur) doit réinitialiser la vue du document. Ce code retour peut être utilisé pour effacer le champ du formulaire du navigateur |
| 206 | Contenu partiel | . Le serveur a traité avec succès certaines requêtes GET |
| Code d'état commençant par 3 | ||
| 300 | Choix multiples | Plusieurs choix. La ressource demandée peut inclure plusieurs emplacements, et par conséquent, une liste de caractéristiques et d'adresses de ressources peut être renvoyée au terminal utilisateur (par exemple : navigateur) pour sélectionner |
| 301 | Déplacé définitivement | Déménager définitivement. La ressource demandée a été définitivement déplacée vers le nouvel URI, les informations renvoyées incluront le nouvel URI et le navigateur sera automatiquement dirigé vers le nouvel URI. Toute nouvelle demande à l'avenir devra utiliser le nouvel URI au lieu de |
| 302 | Trouvé | Temporairement déplacé. Similaire au 301. Mais la ressource n'est déplacée que temporairement. Le client doit continuer à utiliser l'URI d'origine |
| 303 | Voir Autre | pour afficher d'autres adresses. Similaire au 301. Utilisez les requêtes GET et POST pour afficher |
| 304 | Non modifié | Non modifié. La ressource demandée n'a pas été modifiée. Lorsque le serveur renvoie ce code d'état, aucune ressource ne sera renvoyée. Les clients mettent généralement en cache les ressources consultées en fournissant un en-tête indiquant que le client souhaite renvoyer uniquement les ressources modifiées après une date spécifiée |
| 305 | Utiliser le proxy | Utilisez un proxy. La ressource demandée doit être accessible via un proxy |
| 306 | Inutilisé | Un code d'état HTTP obsolète |
| 307 | Redirection temporaire | Redirection temporaire. Similaire au 302. Utiliser la redirection de requête GET |
| Code d'état commençant par 4 | ||
| 400 | Bad Request | Client Le erreur de syntaxe dans la requête de fin, le serveur ne peut pas comprendre |
| 401 | Non autorisé | La requête nécessite une authentification de l'utilisateur |
| 402 | Paiement requis | Réservé pour une utilisation future |
| 403 | Interdit | Serveur compris La demande du client est demandée, mais la demande est refusée à être exécutée |
| 404 | Not Found | Le serveur ne trouve pas la ressource (page web ) en fonction de la demande du client. Grâce à ce code, les concepteurs de sites Web peuvent créer une page personnalisée pour « La ressource que vous avez demandée est introuvable » |
| 405 | Méthode non autorisée | Client La méthode dans la demande du client est interdite |
| 406 | Non acceptable | Le serveur ne peut pas terminer la demande en fonction des caractéristiques de contenu du client demande |
| 407 | Authentification proxy requise | La demande nécessite une authentification proxy, similaire à 401, mais le demandeur doit utiliser le proxy pour l'autorisation |
| 408 | Expiration du délai de demande | Le serveur a attendu trop longtemps la demande envoyée par le client et a expiré |
| 409 | Conflit | Le serveur peut renvoyer ce code lors de la réalisation de la requête PUT du client. Un conflit s'est produit lorsque le serveur a traité la requête |
| Parti | La ressource demandée par le client n'existe plus. 410 est différent de 404. Si la ressource a été définitivement supprimée, le code 410 peut être utilisé. Le concepteur du site Web peut spécifier le nouvel emplacement de la ressource via le code 301 | |
| Longueur requise | Le serveur ne peut pas traiter les informations de la demande sans la longueur de contenu envoyée par le client | |
| Échec de la condition préalable | Erreur de condition préalable pour le client demandant des informations | |
| Entité de demande trop grande | L'entité demandée était trop grande pour que le serveur puisse la gérer , donc la demande a été rejetée. Pour empêcher les demandes continues du client, le serveur peut fermer la connexion.Si le serveur est temporairement incapable de le traiter, il contiendra un message de réponse Retry-After | |
| 414 | Request-URI Too Large | Demandé URI Trop long (l'URI est généralement une URL), le serveur ne peut pas gérer |
| 415 | Type de média non pris en charge | Le serveur ne peut pas gérer le format de média joint à la demande |
| 416 | Plage demandée non satisfiable | La plage demandée par le client est invalide |
| 417 | Échec de l'attente | Le serveur ne peut pas satisfaire les informations d'en-tête de la requête Expect |
| Code d'état commençant par 5 | ||
| 500 | Erreur interne du serveur | Erreur interne du serveur, impossible de terminer la demande |
| 501 | Non implémenté | Le serveur ne le prend pas en charge La fonction demandée n'a pas pu terminer la demande |
| 502 | Bad Gateway | A Le serveur agissant en tant que passerelle ou proxy a reçu une valeur non valide du serveur distant. Demande |
| 503 | Service indisponible | En raison d'une surcharge ou d'une maintenance du système. , le serveur est temporairement incapable de traiter la demande du client. La durée du délai peut être incluse dans les informations d'en-tête Retry-After du serveur |
| 504 | Gateway Time-out | Serveur faisant office de passerelle ou proxy, la requête n'a pas été obtenue du serveur distant à temps |
| 505 | Version HTTP non prise en charge | Le serveur ne prend pas en charge la demande demandée version du protocole HTTP et ne peut pas être terminé. Traitement |
Tableau 2 Tableau d'introduction détaillé
| Code d'état | Signification |
|---|---|
| 100 | Le client doit continuer Envoyez une demande. Cette réponse provisoire permet d'informer le client qu'une partie de sa requête a été reçue par le serveur et n'a pas encore été rejetée. Le client DEVRAIT continuer à envoyer le reste de la demande, ou ignorer cette réponse si la demande a déjà été complétée. Le serveur doit envoyer une réponse finale au client une fois la demande terminée. |
| 101 | Le serveur a compris la demande du client et informera le client via l'en-tête du message de mise à niveau d'utiliser un protocole différent pour terminer la demande. Après avoir envoyé la dernière ligne vierge de cette réponse, le serveur basculera vers les protocoles définis dans l'en-tête Upgrade. Des mesures similaires ne devraient être prises que lorsqu’il serait plus avantageux de passer à un nouveau protocole. Par exemple, il y a des avantages à passer à une nouvelle version HTTP par rapport à une ancienne version, ou à passer à un protocole en temps réel et synchrone pour fournir des ressources qui tirent parti de ces fonctionnalités. |
| 102 | Un code d'état étendu par WebDAV (RFC 2518), indiquant que le traitement va se poursuivre. |
| 200 | La requête a réussi et l'en-tête de réponse ou le corps de données attendu par la requête sera renvoyé avec cette réponse. |
| 201 | La demande a été implémentée et une nouvelle ressource a été créée en fonction des besoins de la demande, et son URI a été renvoyée avec les informations d'en-tête Location. Si les ressources requises ne peuvent pas être créées à temps, « 202 Accepted » doit être renvoyé. |
| 202 | La demande a été acceptée par le serveur mais n'a pas encore été traitée. Tout comme elle peut être refusée, la demande peut finalement être exécutée ou non. Dans le cas d'opérations asynchrones, il n'y a pas de moyen plus pratique que d'envoyer ce code d'état. Le but du renvoi d'une réponse de code d'état 202 est de permettre au serveur d'accepter les demandes d'autres processus (comme une opération par lots qui n'est effectuée qu'une fois par jour) sans avoir à garder le client connecté au serveur jusqu'à l'opération par lots. est terminé. Une réponse qui accepte le traitement de la demande et renvoie un code d'état 202 doit contenir des informations dans l'entité renvoyée indiquant l'état actuel du traitement, ainsi qu'un pointeur vers un moniteur d'état de traitement ou une prédiction d'état afin que l'utilisateur puisse estimer si l'opération a été complété. |
| 203 | Le serveur a traité avec succès la demande, mais les méta-informations d'en-tête d'entité renvoyées ne sont pas un ensemble déterminé valide sur le serveur d'origine, mais proviennent de locaux ou tiers Copie de tiers. Les informations actuelles peuvent être un sous-ensemble ou un sur-ensemble de la version originale. Par exemple, le fait de contenir des métadonnées pour une ressource peut amener le serveur d'origine à connaître les super informations sur les métadonnées. L’utilisation de ce code d’état n’est pas obligatoire et n’est appropriée que si la réponse aurait renvoyé 200 OK sans ce code d’état. |
| 204 | Le serveur a traité avec succès la demande, mais n'a pas besoin de renvoyer le contenu de l'entité et souhaite renvoyer des méta-informations mises à jour. La réponse peut renvoyer des métainformations nouvelles ou mises à jour sous la forme d'en-têtes d'entité. Ces en-têtes, s'ils sont présents, doivent correspondre aux variables demandées. Si le client est un navigateur, le navigateur de l'utilisateur DEVRAIT conserver la page pour laquelle la demande a été faite sans aucune modification de la vue du document, même si des métainformations nouvelles ou mises à jour doivent être appliquées à l'activité du navigateur de l'utilisateur selon la spécification Document en vue. Puisqu'il est interdit à une réponse 204 de contenir un corps de message, elle se termine toujours par la première ligne vide après l'en-tête du message. |
| 205 | Le serveur a traité avec succès la demande et n'a rien renvoyé. Mais contrairement à une réponse 204, une réponse renvoyant ce code d'état nécessite que le demandeur réinitialise la vue du document. Cette réponse est principalement utilisée pour réinitialiser le formulaire immédiatement après avoir accepté la saisie de l'utilisateur afin que celui-ci puisse facilement démarrer une autre saisie. Comme la réponse 204, cette réponse ne peut contenir aucun corps de message et se termine par la première ligne vide après l'en-tête du message. |
| 206 | Le serveur a traité avec succès une partie de la requête GET. Les outils de téléchargement HTTP comme FlashGet ou Thunder utilisent ce type de réponse pour reprendre les téléchargements interrompus ou diviser un document volumineux en plusieurs segments de téléchargement pour un téléchargement simultané. La demande doit inclure un en-tête Range pour indiquer la plage de contenu que le client souhaite obtenir, et peut inclure un If-Range comme condition de demande. La réponse doit inclure les champs d'en-tête suivants : Content-Range est utilisé pour indiquer la plage de contenu renvoyée dans cette réponse s'il s'agit d'un téléchargement en plusieurs parties avec Content-Type multipart/byteranges, chaque multipart ; Chaque paragraphe doit contenir un champ Content-Range pour indiquer la plage de contenu de ce paragraphe. Si un Content-Length est inclus dans la réponse, sa valeur doit correspondre au nombre réel d'octets dans la plage de contenu qu'il renvoie. Date ETag et/ou Content-Location, si la même requête aurait dû renvoyer une réponse 200. Expire, Cache-Control et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses précédentes à la même variable.Si cette demande de réponse utilise la vérification forte du cache If-Range, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité si cette demande de réponse utilise ; Si la validation du cache est faible, cette réponse ne peut pas contenir d'autres en-têtes d'entité ; cela évite les incohérences entre le contenu de l'entité mis en cache et les informations d'en-tête d'entité mises à jour. Sinon, cette réponse doit contenir tous les champs d'en-tête d'entité qui doivent être renvoyés dans une réponse 200. Si les en-têtes ETag ou Last-Modified ne correspondent pas exactement, le cache client ne doit pas combiner le contenu renvoyé par la réponse 206 avec un contenu précédemment mis en cache. Il est interdit à tout cache qui ne prend pas en charge les en-têtes Range et Content-Range de mettre en cache le contenu renvoyé par la réponse 206. |
| 207 | Un code d'état étendu par WebDAV (RFC 2518), indiquant que le corps du message suivant sera un message XML, et peut varier en fonction du nombre de sous-requêtes précédentes, contenant une série de codes de réponse indépendants. |
| 300 | La ressource demandée comporte une série de réponses facultatives, chacune avec sa propre adresse spécifique et ses propres informations de négociation du pilote de navigateur. L'utilisateur ou le navigateur peut choisir une adresse préférée pour la redirection. Sauf s'il s'agit d'une requête HEAD, la réponse doit inclure une entité avec une liste d'attributs de ressources et d'adresses à partir de laquelle l'utilisateur ou le navigateur peut choisir l'adresse de redirection la plus appropriée. Le format de cette entité est déterminé par le format défini par Content-Type. Le navigateur peut automatiquement faire le choix le plus approprié en fonction du format de la réponse et de ses propres capacités. Bien entendu, la spécification RFC 2616 ne précise pas comment une telle sélection automatique doit être effectuée. Si le serveur lui-même dispose déjà d'une option de retour préférée, alors dans L'emplacement doit indiquer l'URI de ce retour ; le navigateur peut utiliser cette valeur d'emplacement comme adresse pour la redirection automatique. De plus, cette réponse peut être mise en cache, sauf indication contraire. |
| 301 | La ressource demandée a été définitivement déplacée vers un nouvel emplacement, et toute référence future à cette ressource doit utiliser l'un des nombreux URI renvoyés avec cette réponse. Si possible, les clients dotés de capacités d'édition de liens doivent automatiquement modifier l'adresse demandée par l'adresse renvoyée par le serveur. Sauf indication contraire, cette réponse peut également être mise en cache. Le nouvel URI permanent doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Remarque : Pour certains navigateurs utilisant le protocole HTTP/1.0, lorsque la requête POST qu'ils envoient reçoit une réponse 301, la requête de redirection suivante deviendra une méthode GET. |
| 302 | La ressource demandée répond désormais temporairement aux requêtes provenant d'un URI différent. Ces redirections étant temporaires, le client doit continuer à envoyer de futures demandes à l'adresse d'origine. Cette réponse peut être mise en cache uniquement si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Remarque : Bien que RFC Les spécifications 1945 et RFC 2068 ne permettent pas au client de modifier la méthode de requête lors de la redirection, mais de nombreux navigateurs existants considèrent la réponse 302 comme une réponse 303 et utilisent la méthode GET pour accéder à l'URI spécifié dans l'emplacement, quel que soit l'original. méthode de demande. Les codes d'état 303 et 307 ont été ajoutés pour clarifier la réponse que le serveur attend du client. |
| 303 | La réponse correspondant à la requête actuelle peut être trouvée sur un autre URI, et le client doit utiliser GET pour accéder à cette ressource. Cette méthode existe principalement pour permettre de rediriger la sortie de la requête POST activée par un script vers une nouvelle ressource. Ce nouvel URI n'est pas une référence de remplacement à la ressource d'origine. Dans le même temps, il est interdit de mettre en cache 303 réponses. Bien entendu, la deuxième requête (redirection) peut être mise en cache. Le nouvel URI doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. REMARQUE : De nombreux navigateurs antérieurs à HTTP/1.1 ne comprennent pas correctement le statut 303. Si vous devez envisager une interaction avec ces navigateurs, le code d'état 302 devrait être suffisant, car la plupart des navigateurs gèrent les réponses 302 exactement de la même manière que la spécification ci-dessus exige que le client gère les réponses 303. |
| 304 | Si le client envoie une requête GET conditionnelle et que la requête est autorisée, et le contenu du document (soit depuis le dernier accès, soit en fonction de la requête condition) n’a pas changé, le serveur doit renvoyer ce code d’état. Il est interdit à une réponse 304 d'inclure un corps de message, elle se termine donc toujours par la première ligne vide après l'en-tête du message.La réponse DOIT contenir les informations d'en-tête suivantes : Date, sauf si le serveur ne dispose pas d'horloge. Si les serveurs sans horloge suivent ces règles, alors les serveurs proxy et les clients peuvent ajouter eux-mêmes le 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 aurait dû renvoyer une réponse 200. Expire, Cache-Control et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses précédentes à la même variable. Si cette demande de réponse utilise une vérification de cache forte, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité ; sinon (par exemple, une requête GET conditionnelle utilise une vérification de cache faible), il est interdit à cette réponse de contenir d'autres en-têtes d'entité, ce qui évite de résoudre les incohérences entre les éléments mis en cache ; contenu de l’entité et informations d’en-tête d’entité mises à jour. Si une réponse 304 indique qu'une entité n'est pas actuellement mise en cache, le système de mise en cache doit ignorer la réponse et répéter la demande sans restriction. Si une réponse 304 est reçue nécessitant une mise à jour d'une entrée de cache, le système de cache doit mettre à jour l'intégralité de l'entrée pour refléter les valeurs de tous les champs qui ont été mis à jour dans la réponse. |
| 305 | La ressource demandée doit être accessible via le proxy spécifié. Le champ Emplacement donnera les informations URI où se trouve le proxy spécifié. Le destinataire doit envoyer à plusieurs reprises une demande distincte pour accéder à la ressource correspondante via ce proxy. Seul le serveur d'origine peut établir une réponse 305. Remarque : La RFC 2068 ne précise pas qu'une réponse 305 est destinée à rediriger une seule requête et ne peut être établie que par le serveur d'origine. Ignorer ces restrictions peut entraîner de graves conséquences en matière de sécurité. |
| 306 | Dans la dernière version de la spécification, le code d'état 306 n'est plus utilisé. |
| 307 | La ressource demandée répond désormais temporairement aux requêtes provenant d'un URI différent. Ces redirections étant temporaires, le client doit continuer à envoyer de futures demandes à l'adresse d'origine. Cette réponse peut être mise en cache uniquement si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. Étant donné que certains navigateurs ne reconnaissent pas la réponse 307, les informations nécessaires ci-dessus doivent être ajoutées afin que les utilisateurs puissent comprendre et faire des demandes d'accès au nouvel URI. S'il ne s'agit pas d'un GET ou d'un HEAD demande, le navigateur interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la demande peuvent changer en conséquence. |
| 400 | 1. La sémantique est incorrecte et la requête actuelle ne peut pas être comprise par le serveur. Le client ne doit pas soumettre à nouveau cette demande à moins qu'elle ne soit modifiée. 2. Les paramètres de la demande sont incorrects. |
| 401 | La demande actuelle nécessite une vérification de l'utilisateur. La réponse DOIT inclure un en-tête WWW-Authenticate approprié à la ressource demandée qui demande des informations à l'utilisateur. Le client peut soumettre à plusieurs reprises une demande contenant l'en-tête d'autorisation approprié. Si la demande actuelle incluait déjà des certificats d'autorisation, la réponse 401 indique que la vérification du serveur a rejeté ces certificats. Si la réponse 401 contient la même requête d'authentification que la réponse précédente et que le navigateur a tenté de s'authentifier au moins une fois, le navigateur doit afficher les informations d'entité contenues dans la réponse à l'utilisateur, car ces informations d'entité peuvent contenir des informations de diagnostic pertinentes. Voir la RFC2617. |
| 402 | Ce code de statut est réservé à d'éventuels besoins futurs. |
| 403 | Le serveur a compris la requête, mais a refusé de l'exécuter. Contrairement à une réponse 401, l’authentification n’apporte aucune aide et la demande ne doit pas être soumise à nouveau. S'il ne s'agit pas d'une requête HEAD et que le serveur souhaite pouvoir expliquer pourquoi la requête ne peut pas être exécutée, alors la raison du rejet doit être décrite dans l'entité. Bien entendu, le serveur peut également renvoyer une réponse 404 s’il ne souhaite pas que le client obtienne des informations. |
| 404 | La requête a échoué. La ressource demandée n'a pas été trouvée sur le serveur. Aucune information n'indique à l'utilisateur si la condition est temporaire ou permanente. Si le serveur connaît la situation, il doit utiliser le code d'état 410 pour informer que l'ancienne ressource est définitivement indisponible en raison de problèmes de mécanisme de configuration interne et qu'il n'y a pas d'adresse de saut. Le code d'état 404 est largement utilisé lorsque le serveur ne souhaite pas révéler la raison pour laquelle la demande a été rejetée ou qu'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 demander la ressource correspondante. La réponse doit renvoyer des informations d'en-tête Allow pour indiquer la liste des méthodes de requête que la ressource actuelle peut accepter. Étant donné que les méthodes PUT et DELETE écriront des ressources sur le serveur, la plupart des serveurs Web ne prennent pas en charge ou n'autorisent pas les méthodes de requête ci-dessus dans la configuration par défaut, et une erreur 405 sera renvoyée pour de telles requêtes. |
| 406 | Les caractéristiques de contenu de la ressource demandée ne peuvent pas satisfaire aux conditions de l'en-tête de la requête, l'entité de réponse ne peut donc pas être générée. Sauf s'il s'agit d'une requête HEAD, la réponse doit renvoyer une entité contenant une liste d'attributs d'entité et d'adresses parmi lesquelles l'utilisateur ou le navigateur peut choisir celui qui est le plus approprié. 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 son propre choix en fonction du format et de ses capacités. Cependant, la spécification ne définit aucun critère pour effectuer de telles sélections automatiques. |
| 407 | Similaire à la réponse 401, sauf que le client doit s'authentifier auprès du serveur proxy. Le serveur proxy doit renvoyer un Proxy-Authenticate pour les requêtes d'identité. Le client peut renvoyer un en-tête Proxy-Authorization pour vérification. Voir la RFC2617. |
| 408 | Délai d'expiration de la demande. Le client n'a pas terminé l'envoi d'une requête dans le délai que le serveur était prêt à attendre. Le client peut soumettre à nouveau cette demande à tout moment sans apporter de modifications. |
| 409 | La demande ne peut pas être complétée en raison d'un conflit avec l'état actuel de la ressource demandée. Ce code ne doit être utilisé que si l'utilisateur est censé être en mesure de résoudre le conflit et de soumettre à nouveau une nouvelle demande. La réponse doit contenir suffisamment d'informations pour que l'utilisateur puisse découvrir la source du conflit. Des conflits surviennent généralement lors du traitement des requêtes PUT. Par exemple, dans un environnement utilisant la vérification de version, si les informations de version jointes à une demande de modification d'une ressource spécifique soumise par un PUT entrent en conflit avec une demande précédente (tiers), le serveur doit alors renvoyer une erreur 409. Informez l'utilisateur que la demande ne peut pas être complétée. À ce stade, l'entité de réponse est susceptible de contenir une comparaison des différences entre les deux versions en conflit, afin que l'utilisateur puisse soumettre à nouveau la nouvelle version après la fusion. |
| 410 | La ressource demandée n'est plus disponible sur le serveur et n'a aucune adresse de redirection connue. Une telle situation devrait être considérée comme permanente. Si possible, les clients disposant de capacités d'édition de liens doivent supprimer toutes les références à cette adresse avec l'autorisation de l'utilisateur. Si le serveur ne sait pas ou ne peut pas déterminer si la condition est permanente, le code d'état 404 doit être utilisé. Sauf indication contraire, cette réponse peut être mise en cache. Le but de la réponse 410 est principalement d'aider les administrateurs du site Web à maintenir le site Web, à informer les utilisateurs que la ressource n'est plus disponible et le propriétaire du serveur espère que toutes les connexions distantes pointant vers cette ressource seront également supprimées. Ce type d’incident est courant dans les services à valeur ajoutée à durée limitée. De même, la réponse 410 est également utilisée pour notifier au client que des ressources appartenant initialement à un individu ne sont plus disponibles sur le site serveur actuel. Bien sûr, devez-vous marquer toutes les ressources indisponibles en permanence comme « 410 » ? Gone', et la question de savoir si cette marque doit être conservée pendant combien de temps dépend entièrement du propriétaire du serveur. |
| 411 | Le serveur a refusé d'accepter la demande sans que l'en-tête Content-Length soit défini. Après avoir ajouté un en-tête Content-Length valide indiquant la longueur du corps du message de la demande, le client peut soumettre à nouveau la demande. |
| 412 | Le serveur n'a pas réussi à satisfaire un ou plusieurs des prérequis indiqués dans les champs d'en-tête de la requête. Ce code d'état permet au client de définir des conditions préalables dans les métainformations de la demande (données du champ d'en-tête de la demande) lors de la récupération de la ressource, empêchant ainsi que la méthode de demande soit appliquée à la ressource autrement que ce qu'elle attend. |
| 413 | Le serveur refuse de traiter la requête en cours car la taille des données d'entité soumises par la requête dépasse la plage que le serveur est disposé ou capable de gérer . Dans ce cas, le serveur peut fermer la connexion pour empêcher le client de continuer à envoyer cette requête. Si la situation est temporaire, le serveur doit renvoyer un en-tête de réponse Retry-After pour informer le client combien de temps plus tard il pourra réessayer. |
| 414 | L'URI demandé est plus long que ce que le serveur peut interpréter, le serveur refuse donc de répondre à la demande. Ceci est relativement rare. Les situations courantes incluent : La soumission du formulaire qui aurait dû utiliser la méthode POST devient la méthode GET, ce qui rend la chaîne de requête trop longue. Redirection de l'URI "trou noir", par exemple, chaque redirection utilise l'ancien URI dans le cadre du nouvel URI, ce qui entraîne un URI trop long après plusieurs redirections. Le client tente d'exploiter les failles de sécurité de certains serveurs pour attaquer le serveur. Ce type de serveur utilise un tampon de longueur fixe pour lire ou exploiter l'URI demandé. Lorsque les paramètres après GET dépassent une certaine valeur, un débordement de tampon peut se produire, provoquant l'exécution de code arbitraire [1]. Les serveurs ne présentant pas de telles vulnérabilités devraient renvoyer un code d'état 414. |
| 415 | Pour la méthode demandée actuelle et la ressource demandée, l'entité soumise dans la demande n'est pas dans un format pris en charge par le serveur, la demande est donc rejetée. |
| 416 | Si la requête contient l'en-tête de requête Range et que toute plage de données spécifiée dans Range ne coïncide pas avec la plage disponible de la ressource actuelle, et que la requête contient Si l'en-tête de requête If-Range n'est pas défini, le serveur doit renvoyer un code d'état 416.Si Range utilise une plage d'octets, cette situation signifie que la position du premier octet de toutes les plages de données spécifiées par la demande dépasse la longueur de la ressource actuelle. Le serveur doit également inclure un en-tête d'entité Content-Range pour indiquer la longueur de la ressource actuelle tout en renvoyant le code d'état 416. Il est également interdit à cette réponse d'utiliser des multiparts/byteranges comme Content-Type. |
| 417 | Le contenu attendu spécifié dans l'en-tête de la requête Expect ne peut pas être satisfait par le serveur, ou le serveur est un serveur proxy et il a des preuves évidentes qu'il l'est non utilisé dans la route actuelle Sur le nœud suivant, le contenu de Expect ne peut pas être satisfait. |
| 421 | Le nombre de connexions au serveur à partir de l'adresse IP du client actuel dépasse la plage maximale autorisée du serveur. Habituellement, l'adresse IP fait référence ici à l'adresse du client vue depuis le serveur (telle que l'adresse de la passerelle de l'utilisateur ou du serveur proxy). Dans ce cas, le nombre de connexions peut impliquer plusieurs utilisateurs finaux. |
| 422 | Le nombre de connexions au serveur à partir de l'adresse IP du client actuel dépasse la plage maximale autorisée du serveur. Habituellement, l'adresse IP fait référence ici à l'adresse du client vue depuis le serveur (telle que l'adresse de la passerelle de l'utilisateur ou du serveur proxy). Dans ce cas, le nombre de connexions peut impliquer plusieurs utilisateurs finaux. |
| 422 | Le format de la requête est correct, mais elle ne peut pas répondre en raison d'erreurs sémantiques. (RFC 4918 WebDAV) 423 Verrouillé La ressource actuelle est verrouillée. (RFC 4918 WebDAV) |
| 424 | La requête actuelle a échoué en raison d'une erreur survenue dans une requête précédente, telle que PROPPATCH. (RFC 4918 WebDAV) |
| 425 | est défini dans le brouillon WebDav Advanced Collections, mais n'apparaît pas dans le protocole de collection de séquences WebDAV (RFC 3658). |
| 426 | Les clients doivent passer à TLS/1.0. (RFC 2817) |
| 449 | Extendu par Microsoft, indique que les requêtes doivent être réessayées après avoir effectué les actions appropriées. |
| 500 | Le serveur a rencontré une condition inattendue qui l'a empêché de terminer le traitement de la demande. D'une manière générale, ce problème se produit lorsqu'il y a une erreur dans le code du programme du serveur. |
| 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 demandée et ne peut prendre en charge sa demande pour aucune ressource. |
| 502 | Un serveur fonctionnant comme passerelle ou proxy a reçu une réponse non valide du serveur en amont lors de la tentative d'exécution d'une requête. |
| 503 | En raison d'une maintenance temporaire ou d'une surcharge du serveur, le serveur est actuellement incapable de traiter la demande. Cette condition est temporaire et sera rétablie après un certain temps. Si un retard peut être attendu, la réponse peut inclure un en-tête Retry-After pour indiquer le retard. Si ce message Retry-After n'est pas donné, le client DEVRAIT le gérer de la même manière qu'il gère une réponse 500. Remarque : L'existence du code d'état 503 ne signifie pas que le serveur doit l'utiliser lorsqu'il est surchargé. Certains serveurs souhaitent simplement refuser les connexions des clients. |
| 504 | Lorsqu'un serveur fonctionnant comme passerelle ou proxy tente d'exécuter une requête, il ne parvient pas à obtenir la requête à temps du serveur en amont (le serveur identifié par l'URI, comme HTTP, FTP, LDAP ) ou un serveur secondaire (par exemple DNS) reçoit une réponse. Remarque : Certains serveurs proxy renvoient une erreur 400 ou 500 lorsqu'une requête DNS expire |
| 505 | Le serveur ne prend pas en charge, ou refuse de prendre en charge, le HTTP version utilisée dans la demande. Cela implique que le serveur ne peut ou ne veut pas utiliser la même version que le client. La réponse doit contenir une entité décrivant pourquoi la version n'est pas prise en charge et quels protocoles le serveur prend en charge. |
| 506 | Extendu par le « Transparent Content Négociation Protocol » (RFC 2295), indiquant que le serveur a une erreur de configuration interne : la ressource d'argument de négociation demandée est configurée être utilisé dans une négociation de contenu transparente et ne constitue donc pas un objectif approprié dans un processus de négociation. |
| 507 | Le serveur ne peut pas stocker le contenu nécessaire pour compléter la demande. Cette condition est considérée comme temporaire. WebDAV (RFC 4918) |
| 509 | Le serveur a atteint sa limite de bande passante. Il ne s’agit pas d’un code de statut officiel, mais il est encore largement utilisé. |
| 510 | Les stratégies requises pour obtenir des ressources ne sont pas respectées. (RFC 2774) |
Enfin, la plupart des informations sont collectées sur Internet Merci à tous les collègues seniors qui ont contribué !
[Cours recommandé : Tutoriel vidéo http]
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
