1 Le protocole HTTP  

Aperçu du chapitre 
 

Les transactions HTTP 
Les URL 
Les requêtes et les réponses HTTP 
Les en‐têtes HTTP 
Les types MIME 
Les témoins (cookies) 
   

9 
 
 1  Programmation du Web 
 

1.1 Introduction
HTTP  (Hypertext  Transfer  Protocol)  est  le  protocole  utilisé  pour  livrer  des 
documents sur le Web. Ces données sont des fichiers HTML, mais peuvent 
également être des fichiers d’image, de vidéo, etc. 

HTTP est un protocole de la couche Application qui utilise TCP pour transpor‐
ter ces messages. Il utilise les fonctions de ce protocole de transport pour 
offrir  un  transfert  fiable,  ce  qui  permet  à  HTTP  de  se  concentrer  sur  des 
aspects d’échange et de négociation des types de données échangées. L’une 
des  forces  de  HTTP  est  sa  simplicité.  Son  ensemble  de  commandes  et  de 
réponses est réduit, mais accompagné de divers en‐têtes qui permettent aux 
clients et aux serveurs d’échanger des informations supplémentaires sur les 
données. 

Le navigateur est le client de HTTP. Il émet des requêtes à un serveur HTTP 
qui lui envoie les réponses. Chaque requête contient une commande spéci‐
fique qui peut être suivie de l’adresse du document suivie d’en‐têtes option‐
nels. La réponse du serveur inclut également des en‐têtes suivis des données. 
Le navigateur utilise le port 80 pour communiquer avec le serveur à travers 
un port TCP. La figure 1.1 montre le modèle d’interaction de HTTP : 

Figure 1.1 Interaction HTTP

Port 80

Requête HTTP Serveur

Navigateur HTTP

Réponse HTTP
Site Client
Ressources Site Serveur
 

HTTP permet l’échange de divers types d’informations appelées Ressources. 
Une  ressource  est  identifiée  par  une  adresse  désignée  par  le  nom  URL 
(Uniform Ressource Locator). Cette ressource peut être un fichier, un pro‐
gramme que le serveur exécute, etc. 

1.2 Les transactions HTTP

HTTP utilise le modèle client/serveur pour ses échanges. Lorsqu’un usager 
qui utilise un navigateur clique sur un lien sur une page Web ou ouvre un 
page à l’aide du navigateur, une requête est émise au serveur. Cette requête 
contient le nom d’une commande à exécuter (par exemple, GET pour obtenir 
un document) et l’URL de la ressource. Le serveur exécute cette commande, 
envoie sa réponse et ferme la connexion.   

10 
 
 Le protocole HTTP  1 
 

L’exemple qui suit illustre une transaction HTTP. Supposons que le client en‐
voie  une  requête  concernant  la  ressource  d’URL  www.info.uqam.ca/
Programmation/tcpip.html. La séquence d’événements est la suivante : 
Le  client  envoie  une  demande  connexion  TCP  au  serveur  HTTP  se 
trouvant à l’adresse www.info.uqam.ca au port 80 (le port 80 étant 
le numéro standard pour le service HTTP). 
Le client HTTP émet une requête HTTP à travers le port associé à la 
connexion TCP qui vient d’être ouverte. Dans cette requête figure le 
chemin relatif qui mène à la ressource Programmation/tcp_ip.html 
sur le site demandé. Ce chemin est relatif à un répertoire spécifique 
sur le serveur, communément appelé DocumentRoot. 
Le serveur HTTP reçoit la réponse à travers le port de la connexion. Il 
recherche  la  ressource  demandée  (c’est‐à‐dire  Programmation/
tcp_ip.html)  sur  son  disque,  l’enveloppe  dans  un  message  HTTP  et 
l’envoie au client à travers ce même port. 
Le serveur HTTP demande la fermeture de la connexion. Cette ferme‐
ture se fait de manière à permettre au message d’atteindre le client. 
C’est une fermeture en mode dit gracieux. 
Le client reçoit la réponse qui contient le document requis et un en‐
tête qui indique qu’il est de type HTML. Le client extrait ce document 
de la réponse et interprète le texte HTML pour l’afficher en mode gra‐
phique. 
Si  ce  document  contient  des  objets  d’autres  types  (par  exemple, 
image, vidéo, etc.), le client doit trouver leurs URL. Pour chacun des 
objets, on doit exécuter une transaction comme celle qu’on vient de 
faire pour la ressource elle‐même. 
Le navigateur affiche alors le document HTML ainsi que tous les objets 
qui y sont référencés. Notons que certains de ces objets pourraient 
nécessiter  de  recourir  à  des  applications  spécifiques  appelées 
applications média (ou helper applications) pour les afficher. C’est le 
cas en particulier des documents audio ou vidéo qui nécessitent des 
applications  de  diffusion  en  continu  (streaming)  telles  Real  Player, 
Windows Media Player, QuickTime Player, etc. Le chapitre 12 traite 
de ces aspects. 

Notons qu’une fois que le serveur a émis sa réponse, il ferme sa connexion 
sans  garder  d’information  sur  la  requête.  C’est  un  serveur  sans  états 
(stateless). Cette caractéristique de HTTP en fait un serveur léger. Cependant, 
comme on le verra plus loin, cela amène quelques complications lorsqu’on 
veut garder des informations pour lier les requêtes d’un même client. C’est 

11 
 
 1  Programmation du Web 
 

le  cas  en  particulier  avec  les  applications  de  commerce  électronique  dans 
lesquelles  les  usagers  consultent  plusieurs  pages  (donc  font  plusieurs 
requêtes)  pour  commander  des  marchandises  (par  exemple,  une  requête 
pour entrer les renseignements personnels et d’autres pour faire le choix des 
marchandises). Nous décrirons plus loin les solutions apportées par certains 
serveurs à ces problèmes. 

1.3 Les URL

Pour  désigner  des  ressources,  HTTP  utilise  une  adresse  appelée  URL 
(Uniform  Resource  Locator).  Une  URL  est  constituée  de  plusieurs  compo‐
santes dont : le protocole utilisé (dans le cas qui nous intéresse, HTTP), le 
nom  de  domaine  du  site  qui  contient  la  ressource,  un  numéro  de  port 
optionnel et un chemin qui mène vers la ressource sur le site du serveur. 

Les URL ont été conçues de manière à pouvoir être utilisées pour désigner 
des ressources pour d’autres services que HTTP (par exemple, FTP, Telnet, 
etc.). La structure de l’URL est la suivante : 

service ://NomDeDomaine :[port]/Chemin

Parmi les services que l’URL peut contenir, on a FTP, Telnet et mailto. Le port 
est celui du service. Lorsque celui‐ci n’apparaît pas dans l’URL, on utilise celui 
défini par défaut pour le service en question. Par exemple, le port par défaut 
pour HTTP est 80, celui de FTP est 21 et celui de Telnet est 23. Le chemin 
désigne  le  nom  de  la  ressource.  Ce  chemin  est  relatif  à  un  répertoire  qui 
désigne le point de départ pour localiser les documents sur le disque du ser‐
veur. Ce répertoire s’appelle généralement document root dans la plupart 
des serveurs HTTP. Lorsque le chemin n’est pas spécifié, un document par 
défaut qui correspond à la page principale du site (accueil ou home page) 
généralement appelé index.html est utilisé. 

Une URL peut contenir d’autres éléments. Par exemple, le chemin peut être 
suivi  d’un  point  d’interrogation  et de paramètres  qu’on fournit  à  une res‐
source  de  type  programme  que  l’on  veut  que  le  serveur  exécute.  Par 
exemple, l’URL suivante : 

http://www.info.uqam.ca/Recherche?oiseaux

Cette URL désigne une ressource programme appelée Recherche à laquelle 
on fournit le paramètre oiseaux.   

12 
 
 Le protocole HTTP  1 
 

On ne peut pas utiliser n’importe quel caractère dans une URL, car certains 
ne sont pas permis et d’autres ont une signification particulière. Lorsqu’on 
doit les utiliser, ils doivent être codés selon un codage URL (URL encoding), 
comme suit : 
Si l’on doit fournir une liste d’éléments, ceux‐ci doivent être séparés 
par le symbole &. C’est le cas par exemple si l’on doit fournir plusieurs 
arguments à un programme dans une URL. 
Si un argument dans une URL comprend des espaces, on les remplace 
par le caractère +. 
Tout autre symbole spécial (par exemple, é) qui figure dans l’URL est 
remplacé par son code ASCII en hexadécimal précédé du symbole %. 
Par exemple, la chaîne Montréal/Jazz dans une URL doit être codée 
Montr%E9al%2FJazz. 

Voici quelques exemples d’URL bien formées : 
http://www.info.uqam.ca /index.html 
http://www.info.uqam.ca 
http://www.info.uqam.ca /Recherche?Abdel+Obaid 
http://www.uqam.ca /Recherche?Musique=Jazz&langue=Anglais 
mailto:obaid.abdel@uqam.ca 
ftp://ftp.info.uqam.ca/PUBLIC/documentation.zip 
telnet://arabica.info.uqam.ca 
http://www.google.ca/search?question=M%E9t%E9o+Montr%E9al 

1.4 Les requêtes et les réponses HTTP

Il existe deux types de messages dans HTTP : les requêtes et les réponses. 
Les deux sont de format similaire. Ils sont constitués d’une suite de lignes 
contenant des caractères en ASCII (voir la figure 1.2). 

Figure 1.2 Format des messages HTTP

   
Méthode URL Version  Ligne de code d’état 
En‐tête 1  En‐tête 1 
En‐tête 2  En‐tête 2 
…  … 
En‐tête n  En‐tête n 
Ligne vide  Ligne vide 
Corps de la requête  Corps de la réponse 
   

(a) Requête  (b) Réponse 
   

13 
 
 1  Programmation du Web 
 

1.4.1 Les requêtes HTTP 
Une requête HTTP est formée d’une suite de lignes composées comme suit : 
une ligne de requêtes contenant la commande de la requête appelée 
Méthode, l’URL de la ressource demandée et la version de HTTP utili‐
sée; 
zéro, une ou plusieurs lignes d’en‐tête; 
une ligne vide; 
le corps de la requête. 

Chaque ligne doit se terminer par le caractère « retour de chariot » (CR ou 
Carriage Return) suivi de « Retour à la ligne » (LF ou line feed). Les champs 
dans chaque ligne sont séparés par un ou plusieurs espacements. 
Le format d’une ligne de requêtes est le suivant : 
<Méthode> <URL> <Version de HTTP>

L’URL désigne la ressource. La version correspond au numéro de version du 
protocole HTTP utilisée. Actuellement, la plupart des serveurs et des naviga‐
teurs  comprennent  la  version  11.  On  spécifie  la  version  sous  la  forme 
HTTP/1.1. 
La méthode indique le type d’opération que l’on veut effectuer sur la res‐
source. Il existe plusieurs méthodes dont : 
GET : Cette méthode permet de lire le document spécifié par l’URL. 
Cette lecture peut être conditionnelle si l’on utilise des en‐têtes qui 
imposent des conditions de lecture. Lorsqu’on utilise un lien sur une 
page Web ou que l’on ouvre une page Web avec le navigateur, c’est 
cette méthode qui est utilisée par défaut. 
Voici un exemple de requête de type GET : 

GET Programmation/tcpip.html HTTP/1.1

<Ligne vide>

Dans la plupart des cas, le corps de la requête est vide. Par contre, les en‐
têtes peuvent être présents. On décrira ces en‐têtes plus loin dans ce cha‐
pitre. 
POST : Cette méthode est utilisée pour soumettre des données à un 
serveur afin qu’il les traite. Les données soumises sont incluses dans 
le corps de la requête. Cette méthode est généralement utilisée pour 
soumettre au serveur des données qu’un usager aura entrées en uti‐
lisant  un  formulaire  sur  une  page  Web.  C’est  le  cas  notamment 
lorsqu’on soumet un fichier à l’aide d’un champ <input> de type file. 
   

14 
 
 Le protocole HTTP  1 
 

Voici un exemple d’utilisation de POST : 
POST Programmation/traitement HTTP/1.1
<Ligne vide>
…
… Donnees …
…

PUT : Cette méthode permet de soumettre un document au serveur. 
Si ce document n’existe pas, il sera créé. S’il y est déjà, il sera rem‐
placé. Ces opérations sont effectuées uniquement si le serveur en 
donne la permission. La différence entre PUT et POST est que l’URL 
dans la requête de type POST désigne une ressource qui doit traiter 
les données soumises alors que dans le cas de PUT elle identifie un 
document dont le contenu se trouve dans le corps de la requête. 
DELETE : Cette méthode demande au serveur de détruire la res‐
source identifiée par l’URL. Bien entendu, cette méthode n’est exé‐
cutée que si le serveur le permet. 
HEAD : Cette méthode permet de lire l’en‐tête associé à un docu‐
ment spécifié par l’URL. Parmi ces en‐têtes, on a la date de création 
du document, la date de sa dernière modification, etc. Cette 
méthode et utilisée pour obtenir des métadonnées sur le document. 
Elle est essentiellement utilisée pour tester la validité de l’URL ou 
l’accessibilité à ce document. 
TRACE : Cette méthode permet au serveur de renvoyer la requête 
envoyée par le client. Elle fait donc une sorte d’opération d’écho. 
OPTIONS : Cette méthode permet d’obtenir des informations sur les 
options ou sur certaines exigences de communication sur la requête 
et la réponse concernant une ressource ou le serveur. Parmi ces 
options figurent la date de création de la ressource, le nom du logi‐
ciel serveur ou la liste des méthodes acceptées par celui‐ci. 

1.4.2 Les réponses HTTP 
À  chaque  requête  HTTP,  le  serveur  répond  par  un  message.  Ces  réponses 
sont formées d’une suite de lignes composées comme suit : 
une  ligne  de  code  d’état  contenant  la  version  de  HTTP  utilisée,  un 
nombre qui indique le type de la réponse et un texte descriptif de ce 
code; 
zéro, une ou plusieurs lignes d’en‐tête; 
une ligne vide; 
le corps de la réponse.   

15 
 
 1  Programmation du Web 
 

Le format d’une ligne de réponse est le suivant : 
<Version HTTP> <Code> <Texte descriptif>

Le numéro du code est composé de trois chiffres qui indiquent si la requête 
a été satisfaite ou non. Le premier chiffre du code indique le type de réponse 
et les deux autres donnent des informations plus spécifiques. 

Voici quelques‐uns de ces codes et leur signification : 
1xx  Information :  Cette  catégorie  de  codes donne  des  informations 
aux clients. 
100  Continue :  Le  serveur  accepte  de  traiter  la  requête  et  le 
client doit continuer. 
101 Changement de protocole : Le serveur comprend la requête, 
mais doit continuer avec une autre version de HTTP. 
2xx Succès : Cette catégorie de codes décrit les cas de succès. 
200 OK : La requête a bien été exécutée. 
201 Créée : La requête a été exécutée et la ressource demandée 
a été créée. 
202  Accepté :  La  ressource  a  été  acceptée  et  le  traitement 
demandé est en cours d’exécution. 
2004  Aucun  contenu :  La  requête  a  été  exécutée,  mais  aucun 
contenu ne doit être retourné. 
3xx Redirection : Cette catégorie de codes décrit des cas de déplace‐
ment de la ressource demandée. 
300 Choix multiples : La ressource demandée correspond à plu‐
sieurs emplacements. Le client est informé pour qu’il puisse en 
choisir un en particulier. 
301  Ressource  déplacée :  La  ressource  demandée  a  changé 
d’emplacement, et ce, de façon permanente. 
304 Non modifié : La ressource demandée n’a pas été modifiée 
depuis la dernière requête. Le client peut utiliser la copie de la 
ressource qui se trouve dans sa mémoire cache. 
4xx : Mauvaise requête : Cette catégorie de codes décrit des cas d’er‐
reur. 
401  Accès  non  autorisé :  La  requête  exige  que  le  client  soit 
authentifié. 
   

16 
 
 Le protocole HTTP  1 
 

403  Interdit :  Le  serveur  a  compris  la  requête,  mais  refuse  de 
l’exécuter. 
404 Non trouvé : Le serveur ne trouve pas la ressource deman‐
dée. 
405  Méthode  non  autorisée :  La  méthode  demandée  dans  la 
requête n’est pas autorisée pour la ressource spécifiée. 
408  Timeout  dans  la  requête :  Le  client  n’a  pas  produit  de 
requête dans un intervalle de temps acceptable par le serveur. 
Il doit répéter sa requête. 
410  Parti :  La  ressource  demandée  n’est  plus  disponible  et 
aucune redirection n’a été spécifiée. 
414 URL trop longue : Le serveur refuse de traiter la requête, car 
l’URL spécifiée dans la requête est trop longue. 
5xx Erreurs du serveur : Cette catégorie de codes décrit des situations 
de problèmes liés au fonctionnement du serveur. 
501  Non  implanté :  Le  serveur  ne  possède  pas  la  fonction 
requise pour traiter la requête. 
503  Service  non  disponible :  Le  serveur  ne  peut  pas  traiter  la 
requête pour des raisons de surcharge temporaire ou de main‐
tenance. Le client doit réessayer plus tard. 
505  Version  de  HTTP  non  offerte :  Le  serveur  n’offre  pas  ou 
refuse d’offrir la version de HTTP demandée dans la requête. 

1.5 Les en‐têtes HTTP

Une ligne de requête ou de réponse peut être suivie de lignes d’en‐tête qui 
permettent de préciser certains de leurs paramètres. Dans ce qui suit, nous 
en présentons quelques‐uns. 

Notons  que  certains  de  ces  en‐têtes  sont  utilisables  dans  les  requêtes  ou 
dans les réponses alors que d’autres peuvent être utilisés dans les deux cas. 
Chaque en‐tête est spécifié en donnant son nom suivi des deux‐points (:), 
suivi de la valeur de l’en‐tête. Par exemple : 

GET Programmation/tcpip.html HTTP/1.0

Connections : close
Host : www.info.uqam.ca
User-agent : Mozilla/5.0
Accept-language : fr
…

   

17 
 
 1  Programmation du Web 
 

Les en‐têtes associés aux requêtes sont les suivants : 
Accept :  peut  être  utilisé  pour  spécifier  les  types  de  médias  accep‐
tables  par  le  navigateur.  Il  indique  que  la  requête  est  limitée  à  un 
ensemble restreint de types de médias, par exemple les images JPEG 
et GIF, que le navigateur peut lui‐même interpréter sans recourir à 
des applications externes. 
Accept‐Charset : indique l’ensemble des caractères acceptables par le 
navigateur. Il spécifie également le codage utilisé pour ces caractères, 
tel que le codage ISO-Latin (nommé ISO-8859-1). 
Accept‐Encoding :  spécifie  les  types  de  codages  acceptables  par  le 
navigateur.  Il  permet  de  spécifier,  par  exemple,  que  le  navigateur 
accepte des données compressées (par exemple utilisant un codage 
tel que .zip). 
Accept‐Language : spécifie les langues (français, anglais, etc.) que le 
navigateur accepte. 
Autorization :  permet  au  client  de  soumettre  des  paramètres  d’au‐
thentification pour une autorisation d’accès. 
Host : contient l’adresse du serveur. 
Cookie : permet au client de présenter une témoin à un serveur qui le 
lui a livré auparavant. Les témoins seront expliqués plus loin dans ce 
chapitre. 
If‐Modified‐Since : ajoute une condition à la requête. Si le contenu de 
la ressource n’a pas été modifié depuis la date spécifiée dans cet en‐
tête, cette ressource n’est pas retournée par le serveur. Le client peut 
alors utiliser la copie qui se trouve dans sa mémoire cache. 
Referer : indique l’URL de la page à partir de laquelle la référence à la 
ressource dans la requête a été obtenue. 
From : contient l’adresse de messagerie électronique de la personne 
qui est en charge du navigateur. 
User‐Agent : donne des informations (nom, version, etc.) sur le logi‐
ciel navigateur utilisé. 
Voici un exemple de requête utilisant certains de ces en‐têtes : 
GET /document1.html HTTP/1.1
Host : www.labunix.uqam.ca
Connection : keep-alive
User-agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) …
Accept : text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
Referer : http://www.labunix.uqam.ca/exemple1.html
Accept-encoding : gzip, deflate
Accept-language : fr-FR, fr;q=0.8, en-US;q=0.6, en;q=0.4
Accept-charset : ISO-8859-1, utf-8;q=0.7, *;q=0.3
Cookie :
__utma=148357171.1616128815.1327369674.1327613087.1328040331.7;
   

18 
 
 Le protocole HTTP  1 
 

Les en‐têtes utilisés dans les réponses sont les suivants : 
Content‐Encoding :  spécifie  le  type  de  codage  du  contenu  de  la 
réponse (exemple, : le contenu de la réponse est compressé au for‐
mat .zip). 
Content‐Language :  décrit  la  langue  (français,  anglais,  etc.)  utilisée 
dans le document inclus dans la réponse. 
Content‐Length :  indique  la  longueur  en  octets  des  données  conte‐
nues dans la réponse. 
Content‐Type : indique le type de contenu de la réponse. Il s’agit du 
type MIME utilisé (voir plus loin pour la description de ces types). 
Expires :  spécifie  la  durée  de  validité  d’un  document  utilisé  pour  la 
gestion des mémoires cache. 
Location : permet au serveur de demander au client de rediriger sa 
requête ailleurs. 
Server : donne des informations (nom, version, etc.) sur le logiciel ser‐
veur (par exemple, Apache, IIS) utilisé. 
Set‐Cookie : Permet au serveur de fournir un témoin au client. 

Les en‐têtes communs aux  requêtes et aux réponses sont les suivants : 
Date : date et heure auxquelles la requête ou la réponse a été émise. 
Upgrade : permet au client et au serveur de spécifier le protocole de 
communication qu’ils offrent et qu’ils souhaiteraient utiliser. 

1.6 Les types MIME

Afin de permettre à des données de divers types d’être échangées entre un 
client et un serveur HTTP, la communauté Internet a introduit un mécanisme 
de  description  des  types  appelé  MIME  (Multipurpose  Internet  Mail  Exten‐
sion). 

Les types MIME peuvent être des données en ASCII simple, étendu, ou des 
types plus complexes tels que des images, des sons, des vidéos, etc. Ils per‐
mettent également des codages spécifiques à des langues ayant des carac‐
tères accentués (telles les langues latines) et même des caractères apparte‐
nant à des langues orientales (telles que le Chinois et l’Arabe), des images 
codées à l’aide de différentes techniques de codage (JPEG, GIF, etc.), de la 
voix,  de  la  vidéo,  etc.  Ces  codes  ont  été  standardisés  par  la  communauté 
d’Internet  sous  des  nomes  tels  que  UTF‐8  (pour  Universal  Transformation 
Format − 8‐bit ), UTF‐16, Unicode, etc. 
   

19 
 
 1  Programmation du Web 
 

MIME  désigne  ces  codages  par  leur  type  et  leur  sous‐type  décrits  à  l’aide 
d’une expression sous la forme type/sous type.  
Certains types définis dans le standard MIME sont : text, image, audio, video 
et application. Pour chacun de ces types, on a plusieurs sous‐types qui cor‐
respondent au codage utilisé. Par exemple, text/html désigne un texte HTML 
et image/gif désigne une image codée en GIF. 
Pour spécifier le type MIME des données incluses dans un message, HTTP 
utilise un en‐tête spécial appelé Content‐type, comme suit : 
Content-type : type/sous-type

Par exemple, pour des données image codées en GIF, on écrira :  

Content-type : image/gif

Un nombre relativement grand de types de données MIME ont été définis, 
dont notamment text/html, text/plain, image/gif, image/jpeg, audio/basic, 
audio/x‐wav, video/mpeg, video/quicktime, application/msword et applica‐
tion/zip. 
Pour préciser la technique de codage utilisée pour un type MIME donné, des 
paramètres  peuvent  être  ajoutés  dans  l’en‐tête  Content‐type  (après  un 
point‐virgule), comme dans : 

Content-type : text/html; charset=iso-8859-1

Content-Type : text/html; charset=utf-8

La première ligne de l’exemple indique que le contenu est HTML et qu’on y 
trouve  des  caractères  codés  selon  le  codage  ISO‐8859‐1,  qui  autorise  les 
caractères latins accentués. La deuxième indique un codage universel. UTF‐
8.  La  page  peut  donc  contenir  des  caractères  autres  que  latins  accentués 
(exemple : des symboles mathématiques). 
Un nombre relativement important de types MIME ont été introduits pour 
désigner  des  documents  produits  par  des  logiciels  spécifiques  à  Microsoft 
tels  que  MS‐WORD.  Parmi  ces  types,  mentionnons  application/msword, 
application/pdf et application/zip. 
Le type MIME multipart peut être utilisé pour indiquer que le contenu est 
composé de plusieurs parties ayant chacune son propre type MIME. 
Il existe plusieurs types MIME de cette catégorie. On peut indiquer qu’il s’agit 
de choix de plusieurs contenus, d’une combinaison de plusieurs contenus, 
etc.  Les  parties  sont  séparées  par  un  séparateur  contenu  dans  le  mot‐clé 
boundary et débutent par un type MIME simple.    

20