Connaissance du protocole http que les développeurs front-end doivent connaître

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 :

Content-RangeServeur : Apache/1.3.27 (Unix) (Red-Hat/Linux)Transfer-Encoding:chunkedVary : * tr>

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)

Header	解释	示例
Accept-Ranges	表明服务器是否支持指定范围请求及哪种类型的分段请求	Accept-Ranges: bytes
Age	从原始服务器到代理缓存形成的估算时间（以秒计，非负）	Age: 12
Allow	对某网络资源的有效的请求行为，不允许则返回405	Allow: GET, HEAD
Cache-Control	告诉所有的缓存机制是否可以缓存及哪种类型	Cache-Control: no-cache
Content-Encoding	web服务器支持的返回内容压缩编码类型。	Content-Encoding: gzip
Content-Language	响应体的语言	Content-Language: en,zh
Content-Length	响应体的长度	Content-Length: 348
Content-Location	请求资源可替代的备用的另一地址	Content-Location: /index.htm
Content-MD5	返回资源的MD5校验值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整个返回体中本部分的字节位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回内容的MIME类型	Content-Type: text/html; charset=utf-8
Date	原始服务器消息发出的时间	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	请求变量的实体标签的当前值	ETag: “737060cd8c284d8af7ad3082f209582d”
Expires	响应过期的日期和时间	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	请求资源的最后修改时间	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	用来重定向接收方到非请求URL的位置来完成请求或标识新的资源	Location: http://www.zcmhi.com/archives/94.html
Pragma	包括实现特定的指令，它可应用到响应链上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出认证方案和可应用到代理的该URL上的参数	Proxy-Authenticate: Basic
refresh	应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）	Refresh: 5; url= http://www.zcmhi.com/archives/94.html
Retry-After	如果实体暂时不可取，通知客户端在指定时间之后再次尝试	Retry-After: 120
Server	web服务器软件名称	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie	设置Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	指出头域在分块传输编码的尾部存在	Trailer: Max-Forwards
Transfer-Encoding	文件传输编码	Transfer-Encoding:chunked
Vary	告诉下游代理是使用缓存响应还是从原始服务器请求	Vary: *
Via	告知代理客户端响应是通过哪里发送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	警告实体可能存在的问题	Warning: 199 Miscellaneous warning
WWW-Authenticate	表明客户端请求实体应该使用的授权方案	WWW-Authenticate: Basic

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

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

Vary

Indique au proxy en aval s'il doit utiliser une réponse ou une demande en cache du serveur d'origine

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

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)

.<.>410PartiLa 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 411<.>412413

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
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!