2. Etude du protocole HTTP (Hyper Text Transfer Protocol)
Le protocole HTTP pour Hyper Text Tranfer Protocol à
été défini au début des années 1990. A l'origine il était uniquement
conçu pour transférer des pages Web au format HTML. Cependant il a connu
diverses évolutions et il peut maintenant être utilisé pour transférer
d'autres types de ressources (images, vidéos, code
SQL obtenu après une requête effectuée auprès d'une base de données, demandes
d'authentifications...). HTTP fonctionne suivant le modèle client
/ serveur où le navigateur Web est le client et une machine exécutant IIS,
Apache ou bien encore Xitami est le serveur. Le port standard du
protocole HTTP est le port 80 en TCP. Bien entendu, n'importe quel autre port TCP peut être utilisé par HTTP (8080, 8081). Une ressources Lambda peut être identifiée par
une adresse ou URL (Uniform Ressource Locator).
Voici les diverses améliorations apportées au protocole HTTP au cours du
temps :
-
la v 0.9 n'est pas une version "commerciale", il s'agit uniquement des
spécification de base posées au début des années 90. Elle permet uniquement d'échanger
des pages Web au format HTML.
-
La v 1.0 a été normalisée en 1996 avec la RFC 1945. Elle permet d'envoyer
n'importe quel type de ressource possédant un type MIME.
-
La v 1.1 a été normalisée en 1997 avec la RFC 2068. Elle ajoute
beaucoup de
nouveautés par rapport à la version 1.0 (meilleurs débits car plusieurs
ressources peuvent être transmises sur une seule connexion grâce aux
connexions persistantes, temps d'accès améliorés grâce à une meilleure gestion du cache, plusieurs domaines
peuvent coexister sur une même IP on parle de serveurs Web multi-sites, support
des méthodes d'authentifications BASIC et DIGEST, support des
images PNG et des feuilles de style CSS...).
-
Quelques améliorations (ajout de nouvelles méthodes...)
ont été apportées à certaines fonction en rapport avec le protocole HTTP,
cependant la version actuelle est toujours la v1.1.
HTTP fonctionne avec un système de requête/réponse à l'instar de beaucoup
d'autres
protocoles (notamment LM, NTLM et Kerberos). Que le message soit une requête du
client ou une réponse du serveur, il est constitué de trois parties : la
ligne de requête/statut, l'en-tête et le corps. Dans certain cas, le message peut se passer de corps mais
la ligne et l'en-tête, elles,
sont toujours présentes ! Si vous souhaitez obtenir plus d'informations sur les
différentes évolutions du protocole HTTP, vous pouvez consulter les RFCs
suivantes :
|
Liens vers les RFCs définissant les versions du
protocole HTTP |
|
Num. |
Titre |
Auteurs |
Date |
| 1945 |
Hypertext Transfer Protocol -- HTTP/1.0 |
T. Berners-Lee, R. Fielding, H.
Frystyk |
Mai 1996 |
| 2068 |
Hypertext Transfer
Protocol -- HTTP/1.1
(version obsolète et remplacée par la RFC 2616) |
R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, T. Berners-Lee |
Janvier 1997 |
| 2616 |
Hypertext Transfer Protocol -- HTTP/1.1
(version revue de la RFC 2068) |
R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee |
Juin 1999 |
|
Une requête est composée d'une ligne de requête, d'un en-tête et
éventuellement d'un corps. La ligne de requête précise la méthode utilisée (GET,
HEAD, POST...), le chemin relatif de la ressource demandée (ex. :
/articles/server/isa2004/5/Default.asp) ainsi que la version du
protocole HTTP supportée par le navigateur. Le tableau ci-dessous liste
les huit méthodes HTTP standard définies dans la RFC 2616 : |
 |
| Champ |
Description |
| GET |
Permet de récupérer un document / une ressources sur un serveur
Web. Une requête utilisant la méthode GET n'utilise pas de corps. C'est de
loin la méthode la plus utilisée pour la navigation Web mais aussi
pour toutes les autres utilisations plus ou moins standard du
protocole HTTP... |
| HEAD |
Identique à GET
mais lorsqu'elle est utilisée le serveur ne doit pas renvoyer de
réponse contenant un corps (en d'autres termes, lorsqu'un serveur
Web reçoit une requête utilisant la méthode HEAD, il est obligé de
renvoyer une réponse sans corps). Cette méthode est uniquement
utilisée pour obtenir des informations sur la ressource demandée ou
le serveur Web (ex. : nom et version du serveur Web). Windows Update
et Microsoft Update utilisent énormément cette méthode. |
| POST |
Permet
d'envoyer des données vers une URL donnée en les mettant dans le corps de la requête. |
| PUT |
Crée ou modifie
une donnée à l'emplacement spécifié dans l'URL. Cette méthode est
notamment utilisée par le protocole WebDAV pour la création des
fichiers (pour la création des dossiers une méthode HTTP non
standard, nommé MKCOL est utilisée). |
| DELETE |
Tente de
supprimer la ressource spécifiée dans l'URL. Cette méthode est aussi
utilisée par le protocole WebDAV pour la suppression d'un fichier ou
d'un dossier. |
| TRACE |
Cette méthode
est utilisée a des fins de test. Lorsque le serveur reçoit une
requête utilisant la méthode TRACE, il renvoie au client une réponse
contenant dans son corps la requête envoyée par le client. Ceci
permet au client de vérifier si la requête qu'il a envoyé à
l'origine a été modifiée ou non par une entité intermédiaire
(routeur, pare-feu...). Pour des raisons de sécurité, il est
recommandé de bloquer cette méthode au niveau des serveurs Web. |
| CONNECT |
Cette méthode
est utilisée lorsqu'un client tente de se connecter via un tunnel à
un serveur Web en passant par un serveur de proxy. Par exemple un
client du proxy se connectant au site
https://www.laboratoire-microsoft.org utilisera cette méthode ! |
| OPTIONS |
Cette méthode
demande au serveur les méthodes autorisée pour accéder à la
ressource précisée dans l'URL de la requête. Par exemple la requête
OPTIONS /Default.asp HTTP/1.1 pourrait renvoyer une réponse
contenant le champ Allow : GET, POST. |
Certaines applications (ce sont souvent des applications Web) utilisent des méthodes
HTTP non standard !!! Ceci pose un problème d'interopérabilité et de
compatibilité puisque toutes les plateformes et toutes les applications ne
supportent pas ces méthodes plus ou moins "exotiques". On peut citer l'exemple
d'Outlook Web Access qui utilise une grand nombre de méthodes non
standard dans sa version dite "étendue". En réalité ces méthodes HTTP
sont reprises du protocole WebDAV (Web Distributed Authoring and
Versioning) qui est une extension du protocole HTTP (pour plus
d'informations sur les méthodes HTTP utilisées par WebDAV, consultez la
RFC 2518).
Or seul le navigateur Internet Explorer supporte WebDAV.
Microsoft, apparemment conscient de ce problème de
compatibilité, a même développé une version dite "de base" d'OWA
utilisant uniquement des méthodes standard. Seule cette dernière version est
utilisable sur les navigateurs alternatifs (Firefox, Opéra,
Amaya, Konqueror...). Le tableau suivant présente un certain nombre
d'applications utilisant des méthodes HTTP non standard. Précisons que ce
tableau est très loin d'être exhaustif étant donné le nombre d'application
utilisant l'encapsulation HTTP :
| Logiciel |
Méthodes HTTP
utilisées |
| Outlook Web Access |
SEARCH, POLL, PROPFIND, BMOVE,
BCOPY, SUBSCRIBE, MKCOL UNSUBSCRIBE, MOVE, PROPPATCH, BPROPPATCH, BDELETE |
| MSN Messenger |
SUBSCRIBE, UNSUBSCRIBE,
SUBSCRIPTIONS, NOTIFY, POLL, PROPFIND, PROPPATCH, ACL |
| Outlook 2003 (RPC over HTTP) |
RPC_IN_DATA, RPC_OUT_DATA |
| Outlook 2003 (Hotmail HTTP) |
PROPFIND, BMOVE, BDELETE |
| NetDrive (client WebDAV) |
COPY, MOVE, LOCK, UNLOCK, PROPFIND,
PROPPATCH, SEARCH, MKCOL |
L'en-tête HTTP constitue la seconde partie d'une requête
HTTP. Il précise la demande du client à l'aide d'un certain nombre de
paramètres comme User-Agent ou bien encore Host. Voici la liste des
paramètres (encore appelés champs HTTP) les
plus utilisés dans les requêtes HTTP :
| Champ |
Description |
| Host |
Nom de domaine pleinement qualifié du site
Web (ex. : www.laboratoire-microsoft.org) |
| User-Agent |
Chaîne de caractère permettant d'identifier
l'application envoyant la requête |
| Accept |
Liste des types MIME acceptées par
l'application cliente |
| Accept-Language |
Langage de l'application cliente |
| Accept-Encoding |
Spécifie les algorithmes de compression
supportés par l'application cliente (cf. :
notre article) |
| Accept-Charset |
Jeux de caractères supportés par le
navigateur (ISO-8859-15, UTF-8...) |
| Connection |
Indique si les connexions persistantes sont
activées ou non |
| Keep-Alive |
Indique le nombre de requêtes pouvant être
envoyée dans une même connexion persistante |
| Refer |
Indique la page actuelle affichée sur le
navigateur |
| Cookie |
Nom et valeur des cookies éventuellement
associés à la page demandée |
Le corps représente la troisième partie d'une requête HTTP.
C'est un élément facultatif; sa présence dépend de la méthode HTTP utilisée. Il contient les données (image, texte, fichier quelconque...) que
l'application cliente envoie au serveur. L'exemple type d'une requête possédant
un corps est l'envoi de données (identifiant et mot de passe) grâce à un formulaire HTML à l'aide de la
méthode POST.
Le tableau ci-dessous présente un modèle de requête HTTP
ainsi qu'un exemple (ici il s'agit d'afficher la page d'accueil du site
www.laboratoire-microsoft.org).
Dans cet exemple la requête HTTP ne contient pas de corps car la méthode GET est
utilisée.

|
Une réponse est composée d'une ligne de statut, d'un en-tête et
éventuellement d'un corps. La ligne de statut précise la version du
protocole HTTP utilisée, le code de réponse (ex. : 304)
ainsi qu'une description en rapport avec ce code de réponse (ex. :
Not Modified). Le tableau ci-dessous liste
la plupart des code de réponse définies dans la RFC 2616. Si vous
souhaitez obtenir des informations détaillées à propos d'un code de
réponse en particulier, consultez directement la RFC 2616
à cette adresse. |
 |
| Code |
Description |
| 1xx |
Informations |
| 100 |
Continue |
| 101 |
Switching Protocols |
| 2xx |
Succès |
| 200 |
OK |
| 201 |
Created |
| 202 |
Accepted |
| 203 |
Non-Authoritative Information |
| 204 |
No Content |
| 205 |
Reset Content |
| 206 |
Partial Content |
| 3xx |
Redirections |
| 300 |
Multiple Choices |
| 301 |
Moved Permanently |
| 302 |
Found |
| 303 |
See Other |
| 304 |
Not Modified |
| 305 |
Use Proxy |
| 306 |
(Unused) |
| 307 |
Temporary Redirect |
| 4xx |
Erreurs du
client |
| 400 |
Bad Request |
| 401 |
Unauthorized |
|
| Code |
Description |
| 402 |
Paiement Required |
| 403 |
Forbidden |
| 404 |
Not Found |
| 405 |
Method Not Allowed |
| 406 |
Not Acceptable |
| 407 |
Proxy
Authentification Required |
| 408 |
Request Timeout |
| 409 |
Conflict |
| 410 |
Gone |
| 411 |
Length Required |
| 412 |
Precondition
Failed |
| 413 |
Request Entity Too
Large |
| 414 |
Request-URI Too
Long |
| 415 |
Unsupported Media
Type |
| 416 |
Request Range Not
Satisfiable |
| 417 |
Exception Failed |
| 5xx |
Erreurs du
serveur |
| 500 |
Internal Server Error |
| 501 |
Not Implemented |
| 502 |
Bad Gateway |
| 503 |
Service Unavaible |
| 504 |
Gateway Timeout |
| 505 |
HTTP Version Not Supported |
|
L'en-tête HTTP constitue la seconde partie d'une réponse
HTTP. Il informe le client d'un certain nombre de paramètres configurés sur
le serveur comme sa version, la taille et le type du contenu renvoyé. Voici la liste des
paramètres (encore appelés champs HTTP) les
plus utilisés dans les réponses HTTP. Attention, les champs utilisés dans une
réponse HTTP sont différents de ceux utilisés dans une requête HTTP !!!
| Champ |
Description |
| Server |
Type et version
du serveur Web (Par exemple : Microsoft-IIS/6.0). |
| X-Powered-By |
Champ optionnel
donnant des informations supplémentaires comme les langages
dynamiques supportés (ASP.NET, PHP...) |
| Connection |
Indique si les
connexions persistantes sont activées ou non sur le serveur. |
| Content-Lenght |
Taille en
octets des données contenues dans le corps (la taille indiquée dans
une réponse ne correspond pas toujours à la taille réelle de la
donnée, puisque le fichier peut être découpé en plusieurs morceaux
si il es trop volumineux et puisque la compression peut être
activée). |
| Content-Language |
Correspond au
langage des données présentes dans le corps de la réponse. |
| Content-Encoding |
Spécifie les
algorithmes de compression supportés par le serveur (cf. :
notre article) |
| Via |
Représente le
dernier serveur de proxy par lequel la réponse est passée avant de
parvenir au client. |
| Expires |
Indique la date
jusqu'à laquelle la donnée peut être gardée en cache par le client
(ou par un serveur de proxy intermédiaire comme ISA Server par
exemple). |
| WWW-Authenticate |
Renvoie la
liste des protocoles d'authentification supportés par le serveur. Ce
champ est obligatoire suite à une réponse 401 - Non autorisé. |
Le corps représente la troisième partie d'une réponse HTTP.
Il est présent dans la plupart des cas (sauf pour certaines méthodes comme
OPTIONS ne demandant pas de données au serveur). Le corps contient les données (image, texte, fichier quelconque...) envoyées
par le serveur. L'exemple type d'une réponse possédant un corps est le code
HTML (ou une image) renvoyé par le serveur Web à la suite d'une requête avec la
méthode GET.
Le tableau ci-dessous présente un modèle de réponse HTTP
ainsi qu'un exemple (ici il s'agit de la réponse du serveur Web hébergeant
le site www.laboratoire-microsoft.org
suite à requête GET sur la page d'accueil). Dans cet exemple le corps de la
réponse HTTP représente le code HTML de la page demandée.

Sommaire
1. Introduction au filtrage applicatif
1.1 Les limitations inhérentes aux règles d'accès
1.2 Présentation des filtres applicatifs d'ISA Server 2004
2. Etude du protocole HTTP (Hyper Text Transfer Protocol)
2.1 Présentation du protocole HTTP
2.2 Fonctionnement d'une requête HTTP
2.3 Fonctionnement d'une réponse HTTP
3. Le filtre HTTP
3.1 Présentation du filtre HTTP
3.2 Les options générales du filtre HTTP
3.3 Le blocage de méthodes
3.4 Le blocage de signatures
3.5 La suppression ou la modification d'en-têtes
3.6 Le blocage des extensions
3.7 Sauvegarder/restaurer une configuration du filtre HTTP
Conclusion
|
|
 |
Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|