HTTP - Champs d'en-tête

Les champs d'en-tête HTTP fournissent les informations requises sur la demande ou la réponse, ou sur l'objet envoyé dans le corps du message. Il existe quatre types d'en-têtes de message HTTP:

• General-header: Ces champs d'en-tête ont une applicabilité générale pour les messages de demande et de réponse.

• Client Request-header: Ces champs d'en-tête s'appliquent uniquement aux messages de demande.

• Server Response-header: Ces champs d'en-tête s'appliquent uniquement aux messages de réponse.

• Entity-header: Ces champs d'en-tête définissent des méta-informations sur le corps de l'entité ou, si aucun corps n'est présent, sur la ressource identifiée par la demande.

En-têtes généraux

Contrôle du cache

Le champ d'en-tête général Cache-Control est utilisé pour spécifier des directives qui DOIVENT être obéies par tout le système de mise en cache. La syntaxe est la suivante:

Cache-Control : cache-request-directive|cache-response-directive

Un client ou serveur HTTP peut utiliser le Cache-controlen-tête général pour spécifier les paramètres du cache ou pour demander certains types de documents à partir du cache. Les directives de mise en cache sont spécifiées dans une liste séparée par des virgules. Par exemple:

Cache-control: no-cache

Le tableau suivant répertorie les directives de requête de cache importantes qui peuvent être utilisées par le client dans sa requête HTTP:

SN	Directive et description de la demande de cache
1	no-cache Un cache ne doit pas utiliser la réponse pour satisfaire une demande ultérieure sans une revalidation réussie avec le serveur d'origine.
2	no-store Le cache ne doit rien stocker sur la demande du client ou la réponse du serveur.
3	max-age = seconds Indique que le client est prêt à accepter une réponse dont l'âge n'est pas supérieur à la durée spécifiée en secondes.
4	max-stale [ = seconds ] Indique que le client est prêt à accepter une réponse qui a dépassé son délai d'expiration. Si des secondes sont données, elles ne doivent pas être expirées de plus de ce temps.
5	min-fresh = seconds Indique que le client est prêt à accepter une réponse dont la durée de vie d'actualisation n'est pas inférieure à son âge actuel plus la durée spécifiée en secondes.
6	no-transform Ne convertit pas le corps de l'entité.
sept	only-if-cached Ne récupère pas de nouvelles données. Le cache peut envoyer un document uniquement s'il est dans le cache et ne doit pas contacter le serveur d'origine pour voir si une copie plus récente existe.

Les directives de réponse de cache importantes suivantes qui peuvent être utilisées par le serveur dans sa réponse HTTP:

SN	Directive et description de la réponse du cache
1	public Indique que la réponse peut être mise en cache par n'importe quel cache.
2	private Indique que tout ou partie du message de réponse est destiné à un seul utilisateur et ne doit pas être mis en cache par un cache partagé.
3	no-cache Un cache ne doit pas utiliser la réponse pour satisfaire une demande ultérieure sans une re-validation réussie avec le serveur d'origine.
4	no-store Le cache ne doit rien stocker sur la demande du client ou la réponse du serveur.
5	no-transform Ne convertit pas le corps de l'entité.
6	must-revalidate Le cache doit vérifier l'état des documents périmés avant de l'utiliser et les documents expirés ne doivent pas être utilisés.
sept	proxy-revalidate La directive proxy-revalidate a la même signification que la directive must-revalidate, sauf qu'elle ne s'applique pas aux caches d'agent utilisateur non partagés.
8	max-age = seconds Indique que le client est prêt à accepter une réponse dont l'âge n'est pas supérieur à la durée spécifiée en secondes.
9	s-maxage = seconds L'âge maximum spécifié par cette directive remplace l'âge maximum spécifié par la directive max-age ou par l'en-tête Expires. La directive s-maxage est toujours ignorée par un cache privé.

Connexion

Le champ d'en-tête général de connexion permet à l'expéditeur de spécifier les options souhaitées pour cette connexion particulière et ne doivent pas être communiquées par des mandataires sur d'autres connexions. Voici la syntaxe simple pour utiliser l'en-tête de connexion:

Connection : "Connection"

HTTP / 1.1 définit l'option de connexion «fermer» pour l'expéditeur pour signaler que la connexion sera fermée après l'achèvement de la réponse. Par exemple:

Connection: close

Par défaut, HTTP 1.1 utilise des connexions persistantes, où la connexion ne se ferme pas automatiquement après une transaction. HTTP 1.0, en revanche, n'a pas de connexions persistantes par défaut. Si un client 1.0 souhaite utiliser des connexions persistantes, il utilise lekeep-alive paramètre comme suit:

Connection: keep-alive

Date

Tous les horodatages HTTP DOIVENT être représentés en heure moyenne de Greenwich (GMT), sans exception. Les applications HTTP sont autorisées à utiliser l'une des trois représentations suivantes d'horodatage:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Ici, le premier format est le plus préféré.

Pragma

Le champ d'en-tête général Pragma est utilisé pour inclure des directives spécifiques à l'implémentation qui pourraient s'appliquer à n'importe quel destinataire le long de la chaîne de demande / réponse. Par exemple:

Pragma: no-cache

La seule directive définie dans HTTP / 1.0 est la directive no-cache et est maintenue dans HTTP 1.1 pour une compatibilité descendante. Aucune nouvelle directive Pragma ne sera définie à l'avenir.

Bande annonce

La valeur du champ général Trailer indique que l'ensemble donné de champs d'en-tête est présent dans la fin d'un message codé avec un codage de transfert fragmenté. Voici la syntaxe du champ d'en-tête Trailer:

Trailer : field-name

Les champs d'en-tête de message répertoriés dans le champ d'en-tête Trailer ne doivent pas inclure les champs d'en-tête suivants:

• Transfer-Encoding

• Content-Length

• Trailer

Encodage de transfert

Le champ d'en-tête général Transfer-Encoding indique quel type de transformation a été appliqué au corps du message afin de le transférer en toute sécurité entre l'expéditeur et le destinataire. Ce n'est pas la même chose que le codage de contenu car les codages de transfert sont une propriété du message, pas du corps de l'entité. La syntaxe du champ d'en-tête Transfer-Encoding est la suivante:

Transfer-Encoding: chunked

Toutes les valeurs de codage de transfert sont insensibles à la casse.

Améliorer

L'en -tête général de mise à niveau permet au client de spécifier les protocoles de communication supplémentaires qu'il prend en charge et qu'il souhaite utiliser si le serveur juge approprié de changer de protocole. Par exemple:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Le champ d'en-tête Upgrade est destiné à fournir un mécanisme simple pour la transition de HTTP / 1.1 à un autre protocole incompatible.

Via

L'en -tête général Via doit être utilisé par les passerelles et les mandataires pour indiquer les protocoles intermédiaires et les destinataires. Par exemple, un message de requête peut être envoyé d'un agent utilisateur HTTP / 1.0 à un proxy interne nommé "fred", qui utilise HTTP / 1.1 pour transmettre la requête à un proxy public sur nowhere.com, qui complète la requête en en le transmettant au serveur d'origine à l'adresse www.ics.uci.edu. La demande reçue par www.ics.uci.edu aurait alors le champ d'en-tête Via suivant:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Le champ d'en-tête Upgrade est destiné à fournir un mécanisme simple pour la transition de HTTP / 1.1 à un autre protocole incompatible.

Attention

L'en -tête général Warning est utilisé pour transporter des informations supplémentaires sur l'état ou la transformation d'un message qui peuvent ne pas être reflétées dans le message. Une réponse peut porter plus d'un en-tête d'avertissement.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

En-têtes de demande client

J'accepte

Le champ d'en-tête de demande Accepter peut être utilisé pour spécifier certains types de supports acceptables pour la réponse. La syntaxe générale est la suivante:

Accept: type/subtype [q=qvalue]

Plusieurs types de supports peuvent être répertoriés séparés par des virgules et la qvalue facultative représente un niveau de qualité acceptable pour les types d'acceptation sur une échelle de 0 à 1. Voici un exemple:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Cela serait interprété comme text/html et text/x-c et sont les types de médias préférés, mais s'ils n'existent pas, envoyez le text/x-dvi entité, et si cela n’existe pas, envoyez le text/plain entité.

Accepter-Charset

Le champ d'en-tête de demande Accept-Charset peut être utilisé pour indiquer quels jeux de caractères sont acceptables pour la réponse. Voici la syntaxe générale:

Accept-Charset: character_set [q=qvalue]

Plusieurs jeux de caractères peuvent être répertoriés séparés par des virgules et la qvalue facultative représente un niveau de qualité acceptable pour les jeux de caractères non préférés sur une échelle de 0 à 1. Voici un exemple:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

La valeur spéciale "*", si elle est présente dans le Accept-Charset champ, correspond à tous les jeux de caractères et si non Accept-Charset l'en-tête est présent, la valeur par défaut est que tout jeu de caractères est acceptable.

Accepter-encodage

Le champ d'en-tête de demande Accept-Encoding est similaire à Accept, mais restreint les codages de contenu qui sont acceptables dans la réponse. La syntaxe générale est:

Accept-Encoding: encoding types

Les exemples sont les suivants:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

Le champ d'en-tête de demande Accept-Language est similaire à Accept, mais restreint l'ensemble des langages naturels qui sont préférés comme réponse à la demande. La syntaxe générale est:

Accept-Language: language [q=qvalue]

Plusieurs langues peuvent être répertoriées séparées par des virgules et la qvalue facultative représente un niveau de qualité acceptable pour les langues non préférées sur une échelle de 0 à 1. Voici un exemple:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Autorisation

La valeur du champ d'en-tête de demande d' autorisation se compose d'informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le domaine de la ressource demandée. La syntaxe générale est:

Authorization : credentials

La spécification HTTP / 1.0 définit le schéma d'autorisation BASIC, où le paramètre d'autorisation est la chaîne de username:password encodé en base 64. Voici un exemple:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

La valeur se décode en est guest:guest123 où guest est l'ID utilisateur et guest123 est le mot de passe.

Biscuit

La valeur du champ d'en-tête de demande Cookie contient une paire nom / valeur d'informations stockées pour cette URL. Voici la syntaxe générale:

Cookie: name=value

Plusieurs cookies peuvent être spécifiés séparés par des points-virgules comme suit:

Cookie: name1=value1;name2=value2;name3=value3

Attendre

Le champ d'en-tête de demande Expect est utilisé pour indiquer qu'un ensemble particulier de comportements de serveur est requis par le client. La syntaxe générale est:

Expect : 100-continue | expectation-extension

Si un serveur reçoit une demande contenant un champ Expect qui inclut une extension d'attente qu'il ne prend pas en charge, il doit répondre avec un état 417 (Expectation Failed).

De

Le champ d'en-tête de demande De contient une adresse de messagerie Internet pour l'utilisateur humain qui contrôle l'agent utilisateur demandeur. Voici un exemple simple:

From: [email protected]

Ce champ d'en-tête peut être utilisé à des fins de journalisation et comme moyen d'identifier la source de demandes invalides ou indésirables.

Hôte

Le champ d'en-tête de demande Host est utilisé pour spécifier l'hôte Internet et le numéro de port de la ressource demandée. La syntaxe générale est:

Host : "Host" ":" host [ ":" port ] ;

UNE hostsans aucune information de port de fin implique le port par défaut, qui est 80. Par exemple, une requête sur le serveur d'origine pour http://www.w3.org/pub/WWW/ serait:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

Si-Match

Le champ d'en-tête de demande If-Match est utilisé avec une méthode pour le rendre conditionnel. Cet en-tête demande au serveur d'exécuter la méthode demandée uniquement si la valeur donnée dans cette balise correspond aux balises d'entité données représentées parETag. La syntaxe générale est:

If-Match : entity-tag

Un astérisque (*) correspond à n'importe quelle entité et la transaction se poursuit uniquement si l'entité existe. Voici des exemples possibles:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Si aucune des balises d'entité ne correspond, ou si "*" est donné et qu'aucune entité actuelle n'existe, le serveur ne doit pas exécuter la méthode demandée et doit renvoyer une réponse 412 (Precondition Failed).

Si-modifié-depuis

Le champ d'en-tête de demande If-Modified-Since est utilisé avec une méthode pour le rendre conditionnel. Si l'URL demandée n'a pas été modifiée depuis l'heure spécifiée dans ce champ, une entité ne sera pas renvoyée par le serveur; à la place, une réponse 304 (non modifiée) sera retournée sans aucun corps de message. La syntaxe générale de if-modified-since est:

If-Modified-Since : HTTP-date

Un exemple du champ est:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si aucune des balises d'entité ne correspond, ou si "*" est donné et qu'aucune entité actuelle n'existe, le serveur ne doit pas exécuter la méthode demandée et doit renvoyer une réponse 412 (Precondition Failed).

Si-Aucun-Match

Le champ d'en-tête de demande If-None-Match est utilisé avec une méthode pour le rendre conditionnel. Cet en-tête demande au serveur d'exécuter la méthode demandée uniquement si l'une des valeurs données dans cette balise correspond aux balises d'entité données représentées parETag. La syntaxe générale est:

If-None-Match : entity-tag

Un astérisque (*) correspond à n'importe quelle entité et la transaction se poursuit uniquement si l'entité n'existe pas. Voici les exemples possibles:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

Le champ d'en-tête de demande If-Range peut être utilisé avec un GET conditionnel pour demander uniquement la partie de l'entité manquante, si elle n'a pas été modifiée, et l'entité entière si elle a été modifiée. La syntaxe générale est la suivante:

If-Range : entity-tag | HTTP-date

Une balise d'entité ou une date peut être utilisée pour identifier l'entité partielle déjà reçue. Par exemple:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Ici, si le document n'a pas été modifié depuis la date donnée, le serveur retourne la plage d'octets donnée par l'en-tête Range, sinon il retourne tout le nouveau document.

If-Unmodified-Since

Le champ d'en-tête de demande If-Unmodified-Since est utilisé avec une méthode pour le rendre conditionnel. La syntaxe générale est:

If-Unmodified-Since : HTTP-date

Si la ressource demandée n'a pas été modifiée depuis l'heure spécifiée dans ce champ, le serveur doit effectuer l'opération demandée comme si l'en-tête If-Unmodified-Since n'était pas présent. Par exemple:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si la demande aboutit à autre chose qu'un état 2xx ou 412, l'en - tête If-Unmodified-Since doit être ignoré.

Max-avant

Le champ d'en-tête de demande Max-Forwards fournit un mécanisme avec les méthodes TRACE et OPTIONS pour limiter le nombre de mandataires ou de passerelles qui peuvent transmettre la demande au serveur entrant suivant. Voici la syntaxe générale:

Max-Forwards : n

La valeur Max-Forwards est un entier décimal indiquant le nombre de fois que ce message de demande peut être retransmis. Ceci est utile pour le débogage avec la méthode TRACE, en évitant les boucles infinies. Par exemple:

Max-Forwards : 5

Le champ d'en-tête Max-Forwards peut être ignoré pour toutes les autres méthodes définies dans la spécification HTTP.

Autorisation par procuration

Le champ d'en-tête de demande Proxy-Authorization permet au client de s'identifier (ou son utilisateur) auprès d'un proxy qui requiert une authentification. Voici la syntaxe générale:

Proxy-Authorization : credentials

La valeur du champ Proxy-Authorization se compose d'informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le proxy et / ou le domaine de la ressource demandée.

Intervalle

Le champ d'en-tête de demande Range spécifie la ou les plages partielles du contenu demandé à partir du document. La syntaxe générale est:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

La valeur first-byte-pos dans une spécification de plage d'octets donne le décalage d'octet du premier octet d'une plage. La valeur last-byte-pos donne le décalage d'octet du dernier octet de la plage; autrement dit, les positions d'octet spécifiées sont inclusives. Vous pouvez spécifier une unité d'octets sous forme d'octets. Les décalages d'octets commencent à zéro. Quelques exemples simples sont les suivants:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Plusieurs plages peuvent être répertoriées, séparées par des virgules. Si le premier chiffre de la ou des plages d'octets séparés par des virgules est manquant, la plage est supposée compter à partir de la fin du document. Si le deuxième chiffre est manquant, la plage va de l'octet n à la fin du document.

Référent

Le champ d'en-tête de demande Referer permet au client de spécifier l'adresse (URI) de la ressource à partir de laquelle l'URL a été demandée. La syntaxe générale est la suivante:

Referer : absoluteURI | relativeURI

Voici un exemple simple:

Referer: http://www.tutorialspoint.org/http/index.htm

Si la valeur du champ est un URI relatif, il doit être interprété par rapport à Request-URI .

TE

Le champ d'en-tête de demande TE indique quel codage de transfert d' extension il est prêt à accepter dans la réponse et s'il est disposé ou non à accepter les champs de fin dans un codage de transfert fragmenté . Voici la syntaxe générale:

TE   : t-codings

La présence du mot-clé "remorques" indique que le client est prêt à accepter les champs de fin dans un codage de transfert fragmenté et il est spécifié de l'une des manières suivantes:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Si la valeur de champ TE est vide ou si aucun champ TE n'est présent, alors seul le codage de transfert est fragmenté . Un message sans codage de transfert est toujours acceptable.

Agent utilisateur

Le champ d'en-tête de demande User-Agent contient des informations sur l'agent utilisateur à l'origine de la demande. Voici la syntaxe générale:

User-Agent : product | comment

Exemple:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

En-têtes de réponse du serveur

Accepter les plages

Le champ d'en-tête de réponse Accept-Ranges permet au serveur d'indiquer son acceptation des demandes de plage pour une ressource. La syntaxe générale est:

Accept-Ranges  : range-unit | none

Par exemple, un serveur qui accepte les demandes de plage d'octets peut envoyer:

Accept-Ranges: bytes

Les serveurs qui n'acceptent aucun type de demande de plage pour une ressource peuvent envoyer:

Accept-Ranges: none

Cela conseillera au client de ne pas tenter une demande de plage.

Âge

Le champ d'en-tête de réponse Age transmet l'estimation de l'expéditeur du temps écoulé depuis que la réponse (ou sa revalidation) a été générée sur le serveur d'origine. La syntaxe générale est:

Age : delta-seconds

Les valeurs d'âge sont des entiers décimaux non négatifs, représentant le temps en secondes. Voici un exemple simple:

Age: 1030

Un serveur HTTP / 1.1 qui inclut un cache doit inclure un champ d'en-tête Age dans chaque réponse générée à partir de son propre cache.

ETag

Le champ d'en -tête de réponse ETag fournit la valeur actuelle de l'étiquette d'entité pour la variante demandée. La syntaxe générale est:

ETag :  entity-tag

Voici quelques exemples simples:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Emplacement

Le champ d'en-tête de réponse Location est utilisé pour rediriger le destinataire vers un emplacement autre que l'URI de la demande pour qu'il soit terminé. La syntaxe générale est:

Location : absoluteURI

Voici un exemple simple:

Location: http://www.tutorialspoint.org/http/index.htm

Le champ d'en-tête Content-Location diffère de Location en ce que Content-Location identifie l'emplacement d'origine de l'entité incluse dans la demande.

Authentification proxy

Le champ d'en-tête de réponse Proxy-Authenticate doit être inclus dans le cadre d'une réponse 407 (Proxy Authentication Required). La syntaxe générale est:

Proxy-Authenticate  : challenge

Réessayer après

Le champ d'en-tête de réponse Retry-After peut être utilisé avec une réponse 503 (Service non disponible) pour indiquer combien de temps le service devrait être indisponible pour le client demandeur. La syntaxe générale est:

Retry-After : HTTP-date | delta-seconds

Exemples:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Dans ce dernier exemple, le délai est de 2 minutes.

Serveur

Le champ d'en-tête de réponse du serveur contient des informations sur le logiciel utilisé par le serveur d'origine pour traiter la demande. La syntaxe générale est:

Server : product | comment

Voici un exemple simple:

Server: Apache/2.2.14 (Win32)

Si la réponse est transmise via un proxy, l'application proxy ne doit pas modifier l'en-tête de réponse du serveur.

Set-Cookie

Le champ d'en-tête de réponse Set-Cookie contient une paire d'informations nom / valeur à conserver pour cette URL. La syntaxe générale est:

Set-Cookie: NAME=VALUE; OPTIONS

L'en-tête de réponse Set-Cookie comprend le jeton Set-Cookie, suivi d'une liste séparée par des virgules d'un ou plusieurs cookies. Voici les valeurs possibles que vous pouvez spécifier comme options:

SN	Options et description
1	Comment=comment Cette option peut être utilisée pour spécifier tout commentaire associé au cookie.
2	Domain=domain L'attribut Domaine spécifie le domaine pour lequel le cookie est valide.
3	Expires=Date-time La date d'expiration du cookie. S'il est vide, le cookie expirera lorsque le visiteur quittera le navigateur.
4	Path=path L'attribut Path spécifie le sous-ensemble d'URL auquel ce cookie s'applique.
5	Secure Il demande à l'agent utilisateur de ne renvoyer le cookie que sous une connexion sécurisée.

Voici un exemple d'en-tête de cookie simple généré par le serveur:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Varier

Le champ d'en-tête de réponse Vary spécifie que l'entité a plusieurs sources et peut donc varier en fonction de la liste spécifiée d'en-tête (s) de demande. Voici la syntaxe générale:

Vary : field-name

Vous pouvez spécifier plusieurs en-têtes séparés par des virgules et une valeur d'astérisque "*" signale que les paramètres non spécifiés ne sont pas limités aux en-têtes de demande. Voici un exemple simple:

Vary: Accept-Language, Accept-Encoding

Ici, les noms de champ sont insensibles à la casse.

Authentification WWW

Le champ d'en-tête de réponse WWW-Authenticate doit être inclus dans les messages de réponse 401 (non autorisés). La valeur du champ se compose d'au moins un défi qui indique le ou les schémas d'authentification et les paramètres applicables à l'URI de demande. La syntaxe générale est:

WWW-Authenticate : challenge

La valeur du champ WWW-Authenticate peut contenir plusieurs défis, ou si plus d'un champ d'en-tête WWW-Authenticate est fourni, le contenu d'un défi lui-même peut contenir une liste de paramètres d'authentification séparés par des virgules. Voici un exemple simple:

WWW-Authenticate: BASIC realm="Admin"

En-têtes d'entité

Autoriser

Le champ d'en-tête de l'entité Autoriser répertorie l'ensemble des méthodes prises en charge par la ressource identifiée par l'URI de demande. La syntaxe générale est:

Allow : Method

Vous pouvez spécifier plusieurs méthodes séparées par des virgules. Voici un exemple simple:

Allow: GET, HEAD, PUT

Ce champ ne peut pas empêcher un client d'essayer d'autres méthodes.

Encodage de contenu

Le champ d'en-tête d'entité Content-Encoding est utilisé comme modificateur du type de média. La syntaxe générale est:

Content-Encoding : content-coding

Le codage de contenu est une caractéristique de l'entité identifiée par l'URI de demande. Voici un exemple simple:

Content-Encoding: gzip

Si le codage de contenu d'une entité dans un message de demande n'est pas acceptable pour le serveur d'origine, le serveur doit répondre avec un code d'état 415 (type de support non pris en charge).

Contenu-Langue

Le champ d'en-tête d'entité Content-Language décrit le (s) langage (s) naturel (s) du public visé pour l'entité incluse. Voici la syntaxe générale:

Content-Language : language-tag

Plusieurs langues peuvent être répertoriées pour le contenu destiné à plusieurs publics. Voici un exemple simple:

Content-Language: mi, en

L'objectif principal de Content-Language est de permettre à un utilisateur d'identifier et de différencier les entités en fonction de la langue préférée de l'utilisateur.

Content-Length

Le champ d'en-tête d'entité Content-Length indique la taille du corps d'entité, en nombre décimal d'OCTET, envoyé au destinataire ou, dans le cas de la méthode HEAD, la taille du corps d'entité qui aurait été envoyé, si la demande avait été un GET. La syntaxe générale est:

Content-Length : DIGITS

Voici un exemple simple:

Content-Length: 3495

Tout Content-Length supérieur ou égal à zéro est une valeur valide.

Emplacement du contenu

Le champ d'en-tête d'entité Content-Location peut être utilisé pour fournir l'emplacement de ressource pour l'entité incluse dans le message lorsque cette entité est accessible à partir d'un emplacement distinct de l'URI de la ressource demandée. La syntaxe générale est:

Content-Location:  absoluteURI | relativeURI

Voici un exemple simple:

Content-Location: http://www.tutorialspoint.org/http/index.htm

La valeur de Content-Location définit également l'URI de base de l'entité.

Contenu-MD5

Le champ d'en-tête d'entité Content-MD5 peut être utilisé pour fournir un condensé MD5 de l'entité pour vérifier l'intégrité du message à la réception. La syntaxe générale est:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Voici un exemple simple:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Le résumé MD5 est calculé sur la base du contenu du corps d'entité, y compris tout codage de contenu qui a été appliqué, mais sans inclure tout codage de transfert appliqué au corps du message.

Gamme de contenu

Le champ d'en-tête d'entité Content-Range est envoyé avec un corps d'entité partiel pour spécifier où dans le corps d'entité complet le corps partiel doit être appliqué. La syntaxe générale est:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Exemples de valeurs byte-content-range-spec, en supposant que l'entité contient un total de 1234 octets:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Lorsqu'un message HTTP inclut le contenu d'une seule plage, ce contenu est transmis avec un en-tête Content-Range et un en-tête Content-Length indiquant le nombre d'octets réellement transférés. Par exemple,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Type de contenu

Le champ d'en-tête d'entité Content-Type indique le type de média du corps d'entité envoyé au destinataire ou, dans le cas de la méthode HEAD, le type de média qui aurait été envoyé si la demande avait été un GET. La syntaxe générale est:

Content-Type : media-type

Voici un exemple:

Content-Type: text/html; charset=ISO-8859-4

Expire

Le Expires champ en -tête de l' entité donne la date / heure , après quoi la réponse est considérée comme obsolète. La syntaxe générale est:

Expires : HTTP-date

Voici un exemple:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Dernière modification

Le champ d'en-tête d'entité Last-Modified indique la date et l'heure auxquelles le serveur d'origine pense que la variante a été modifiée pour la dernière fois. La syntaxe générale est:

Last-Modified: HTTP-date

Voici un exemple:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT