Protocole http - mise à jour

Soyez le premier à donner votre avis sur cette source.

Vue 8 578 fois - Téléchargée 415 fois

Description

========================================
LE PROTOCOLE HTTP/1.0 - 22:16 18/09/2002
========================================
>> www.myhackerside.fr.St <<
Programmation Rézo

Intro :
=-=-=-=
Ce document à été redigé par C. CHIRIAC , et à été repris depuis le document
rfc1945, mais en résumé . Il ne contient pas donc toutes les informations
mais permet de se faire une idée simpliste sur le protocole HTTP .
En effet , je trouve barbant de lire 54 pages pour enfaite en comprendre
que 10 page au max , j'ai donc repris ce document , et recopié en plus
simple les informations indispensables au bon fonctionnement du server
HTTP style Apache . En même temps ça m'a servi à apprendre :) , et je
vais partager ce que j'ai compris avec vous ;) ...

Vous utilisez ça tous les jours alors certains trucs comme la methode get vous
semblera évidente, mais bon fallais comme même l'expliquer pour faire pro :P .
Bonne prog à tous , akh .

Les types de methode :
=-=-=-=-=-=-=-=-=-=-=-=

GET / HEAD / POST
Si la methode est une autre le server renvoye erreur 501 : Not Implemented
Certains caractére peuvent apparaitre sous la form %HEX HEX (ex %AF )

- METHODE GET :
Elle demande au server des informations , avec des headers , du style MINE .
Avec la methode Get , il faut prendre en compte le champ : If-Modified-Since !

- METHODE HEAD :
Elle est identique à la methode Get , sauf qu'à l'origine elle ne doit pas contenir
de headers Mine , et le server ne devras pas en retourner aussi .
Elle va donc ignorer les headers envoyés , et n'envoyer que le contenu du document .

- METHODE POST :
Elle indique au server de faire suivre les informations headers vers les document
du uri demandé , donc en quelques sorte elle fait suivre les varaiables vers les
scripts ...
Vu que le script n'est pas obligé de répondre , les réponses du server devraient être :
code 200 (OK) ou 204 (pas de contenu)
NB1 : Un champ Content-Length est obligatoire dans le contenu de la requette POST , et la longeur
des informations spécifiées devra être correctement introduite . Dans le cas contraire
le server répondra un message 400 (requête incorrecte) !
NB2 : Aucun cache ne peut être disponible pour ce type de requette vu que la réponse
n'est pas tj la même .

Les réponses des servers :
=-=-=-=-=-=-=-=-=-=-=-=-=-=

· 1xx: Information - Non utilisé, pour usage futur
· 2xx: Succès - L'action a été correctement reçue, interprétée, et exécutée.
· 3xx: Redirection - Une décision supplémentaire doit être prise pour terminer la requête
· 4xx: Erreur Client - La requête présente une erreur de forme et ne peut être satisfaite
· 5xx: Erreur Serveur - La requête est valide, mais le serveur ne peut la satisfaire

Réponses par défault :
| "200" ; OK OK
| "201" ; Created Créé
| "202" ; Accepted Accepté
| "204" ; No Content Pas de contenu
| "301" ; Moved Permanently Changement définitif
| "302" ; Moved Temporarily Changement temporaire
| "304" ; Not Modified Non modifié
| "400" ; Bad Request Requête incorrecte
| "401" ; Unauthorized Non autorisé
| "403" ; Forbidden Interdit
| "404" ; Not Found Non trouvé
| "500" ; Internal Server Error Erreur interne serveur
| "501" ; Not Implemented Non implémenté
| "502" ; Bad Gateway Erreur de routeur
| "503" ; Service Unavailable Indisponible

- Les informations 1xx :
Cette classe de réponse est actuellement réservée pour de futures applications, et
consiste en des messages avec une ligne d'état, des champs d'en-têtes éventuels,
et terminés par une ligne vide (CRLFCRLF).
HTTP/1.0 ne définit actuellement aucun de ces codes, lesquels ne constituent pas une
réponse valide à des requêtes HTTP/1.0. Il restent cependant exploitables à titre
expérimental, dépassant le contexte de la présente spécification.
NB : Comprenez ce que vous en voulez , mais ce type de réponses n'est pas encore utilisé ...

- Les succés 2xx :
  • 200 Ok : Indique que la requette à été reçue , que le script ou le server va renvoyer un

contenu .
  • 201 Crée : Indique qu'une ressource à été crée sur le server .

NB : Cette réponse doit être envoyé aprés que le server ait crée la ressource .
  • 202 Accepté : La requette à été reçue et interprétée correctement, seulement

le server n'a pas encore finit de créer la ressource ...
PS : Ceci equivaut aux obligations du time out d'execution des scripts ...
  • 204 Pas de Contenu : Ce code indique que le server à compris la requette, mais qu'aucune réponse

ne peut être donée, soit parceque le document est vide , soit parceque le script
ne renvoye aucune réponse .

- Redirection 3xx : Il permet de faire des redirections de requettes
  • 300 Choix Multiples : Le document se trouve à plusieurs emplacements sur le server, et

leur emplcaments seronts indiqués par la champ Location .
  • 301 Changement de champ définitive : L'url indiqué sera changée et lorsque l'utilisateur

rentre une nouvelle fois la mauvaise url , elle sera automatiquement redirigée
vers la variable champ définie par Location comme pour la réponse 300 .
  • 302 Changement d'adresse Temporaire : La requette est dirigée mais pas enregistrée puisque

l'url ne sera pas tj redirigé .
  • 304 Non modifié : Ceci correspond aux requette Get qui contiennet la valeur If-Since-Modified,

et indiquent au client que le document n'a pas été modifié , donc disponible en cache .

- Erreurs 4xx: Coté client
  • 400 Requette incorrecte : La requette du client à une erreur de syntaxe ou semble ne pas

avoir été comprise .
  • 401 Non autorisé : Ceci est la réponse quand une page à besoin d'une autentification pour

etre envoyée , cad que la requette doit comporter le champ WWW-Authenticate . Si c'est le cas
et que le server renvoye la même réponse c'est que la valeur contenue dans le champ est mauvaise
(Pas le bon mot de passe quoi ...)
  • 403 Interdit : Le server ne veut pas afficher les infos concernant cette ressource .
  • 404 Non trouvé : Le server ne trouve pas la ressource demandée dans l'uri .


- Erreurs 5xx: Coté server
  • 500 Erreur interne : Le server à planté d'une erreur quelconque ...
  • 501 Non Implementé : Le server ne sait pas comment répondre à la requette .
  • 502 Erreur de routeur : C'est dans le cas où le server sert de routeur ou

de proxy , il à reçu une requette incorrecte .
  • 503 Service Indisponible : Le server ne pêut traiter la requette pour cause

de maintenance ou pour cause de surcharge de requettes .

Les Champs d'entête :
=-=-=-=-=-=-=-=-=-=-=

Légende :
  • Correspond à un champ envoyé par le client

+ Correspond à un champ envoyé par le server
- Correspond à un champ envoyé par le server ou le client

+ Allow : Sert au server de dire quelle genre de requette est supporté par l'url
qu'il appele :
Allow: GET, HEAD
  • Authorization : Aprés une réponse 401 du server , ce champ peut être envoyé

dans envoyé au server dans l'entete :
Authorization: données_identification

+ Content-Encoding : Donne le type d'encodage de l'information , si par exemple
se trouve sous une forme compresée , le client saura la decompresser lors de
son utilisation :
Ex : Content-Encoding: x-gzip
x-gzip
Un format de compression géré par le programme de compression "gzip" (GNU zip)
développé par Jean-Loup Gailly. Ce codage est de type Lempel-Ziv (LZ77) avec
CRC sur 32 bits.
x-compress
Un format de compression géré par le programme "compress" effectuant une compression
adaptative de type Lempel-Ziv-Welch (LZW).

- Content-Lenght : Il indique le nombre de caractéres qui sont en reponse , et dans le
cas d'une requette head , il indique la taille du document renvoyé .
Attention : Toute valeur supérieure ou inférieure indiquée en requette POST , envoyant les
informations variables , ne sera pas comprise par le server , et celui-ci vous renverra
une réponse invalide .
Elle est indispensable dans toutes les requettes POST contenant un corp de variables !

+ Content-Type : Elle indique le type de média envoyé au client .
Ex : Content-Type: text/html

+ Date : Ce champ indique la date exacte avant l'envoie du message , ce qui ensuite
peut permettre da calculer le temps de chargement .
Ex : Date: Tue, 15 Nov 1994 08:12:31 GMT
Syntaxe de Date :
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, mis à jour par la RFC 1123 : celui par défault
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsolète depuis la RFC 1036
Sun Nov 6 08:49:37 1994 ; Format asctime() du C ANSI

Si on ne met pas le format par défault , il faut en prévenir le client avec ce champ :
HTTP-date = rfc1123-date | rfc850-date | asctime-date

+ Expires : Ce champ indique la date et l'heure ou ce document devient obsoléte.
Exemple : Expires: Thu, 01 Dec 1994 16:00:00 GMT
NB : Avec ce champ on indique au client s'il doit ou non prendre en compte le message,
cependant on ne peut pas l'obliger à ce qu'il rafraichisse son cache .
  • From : Ce champ est un mouchard utilisé par certain navigateur qui indique l'adresse

mail du client , et qui peut être un outil de suivi pour les admin ... mais bon , il
est praticment pas utilisé ...
  • If-Modified-Since : Permet d'optimiser la navigation , car en effet , si le server n'a

pas modifié son document depuis , et que le client inclut ce champ , la conversation
se termine par un réponse type 304 (non modifié) .

+ Last-Modified : Indique la date de la derniére modification subie par le document ,
ainsi l'explorateur le charge en cache , et ainsi une fois l'uri redemandée , inclut
le champ If-Modified-Since dans la requette .

+ Location : Ce champ indique l'emplacement exact du document demandé . Il est utilisé
lors des changements de servers avec les reponses 3XX .

- Pragma : Il contient un peu n'importe quoi. Il est définit par les clients , en fonction
du protocole , bréf il peu changer en fonction de ce que le server et l'utilisateur ont
choisit comme protocole . Le plus souvent il contient la valeur no-cache, ce qui indique
au client que la page envoyée ne doit pas être enregistrée en cache .
  • Referer : Ce champ contient l'url de la page précédente , donc permet de savoir comment

l'utilisateur à accédé aux pages . Ce champ n'est pas écrit lorsque l'utilisateur
ecrit à la main l'adresse du site . Ceci permet de cibler les liens sur la toile et les
habitudes des clients , plus de prendre en compte les moteurs de recherches .

+ Server : Ceci permet à donner le nom du server et sa version , cependant le client
n'en prend pas compte . Il est fortement conséillé de ne pas donner ces indications
car en ayant le server et sa version on peut savoir si le server est sujets à certaines
failles , ou à été patché !
  • User-Agent : Il permet de renseigner le server sur le type d'OS que posséde le client

ainsi que sur le navigateur choisit , cependant c'est un mouchard servant à des buts
statistiques , puisque n'importe quel information peut être mise dedans .
  • WWW-Authenticate : Il contient l'authentification saisie par l'utilisateur quand une

réponse de server est 401 (non autorisé).

Source / Exemple :


' VBASE Server - Version BETA
' Il gére peu le protocole HTTP
' mais cela va changer avec la v1
' http://www.vbfrance.com/article.aspx?Val=5745 

' Si vous souhaitez approfondir vos recherches 
' j'ai joint aussi le zip avec le document officiel 
' traduit en français  ...

Conclusion :


Une derniére mise à jour est à prévoir , car je n'ait pas traité
la partie protection/sécurité qui ont étés prévus dans le HTTP .
J'essayerais de trouver un algorithme de cryptage des headers
WWW-Authetificate .

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
575
Date d'inscription
dimanche 23 décembre 2001
Statut
Membre
Dernière intervention
23 octobre 2012

Ca fesait un bail que je n'avais plus lu tout ça :) - je sais pas s'il y en a qui ont remarqué, mais j'avais fait une faute sur la méthode head - en réalité elle sert à lire le statut d'un fichier sans en lire le contenu. Elle sert comme un moyen de vérif de l'état du cache avant d'executer une requette GET par exemple.

Bonne prog à tous,
akh
Messages postés
35
Date d'inscription
mercredi 4 octobre 2006
Statut
Membre
Dernière intervention
23 avril 2009

Trés bon tuto ;p
Je suis avec toi ! Les noob qui note sans réfléchir c'est chiant ;p

Bonne continuation !
Messages postés
27
Date d'inscription
vendredi 22 août 2003
Statut
Membre
Dernière intervention
23 décembre 2017

Des fautes d'ortographe, on en fait tous ! ou presque. Par contre par moment ces fautes trahissent le sens du texte et perturbent sa compréhension. De plus le "vrai" RFC en français est disponible : http://abcdrfc.online.fr/rfc-vf/rfc1945.html
Ceci dit, saluons l'effort d'avoir fait ce tutoriel.
Messages postés
62
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
2 septembre 2008

VBModerateur, je ne veux pas vous vexer, mais dans vos propos, j'ai constaté pas moins de cinq ou six fautes d'orthographes! Avant de reprocher la qualité de la langue française à quiquonque, il faudrait également soigner la nôtre aussi!

J'essais de bien écrire ma langue maternelle moi aussi. Mais notre langue est tellement complexe que ca prend bcp d'effort pour être capable de corriger nos fautes. Ici, ce qui est important, c'est apprentissage! Biensûr qu'il faut que les tutoriaux soient bien rédigés, mais le but premier est de permettre un apprentissage collectif :)

Voilà!

PaT , seulement mon opinion!
Messages postés
32
Date d'inscription
samedi 26 juin 2004
Statut
Membre
Dernière intervention
15 novembre 2004

Rien à dire à part bravo, merci, et MDR
C'est pathétique comme l'a dit darkstone91 =)
Afficher les 25 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.