Protocole http - mise à jour
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 :
contenu .
NB : Cette réponse doit être envoyé aprés que le server ait crée la ressource .
le server n'a pas encore finit de créer la ressource ...
PS : Ceci equivaut aux obligations du time out d'execution des scripts ...
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
leur emplcaments seronts indiqués par la champ Location .
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 .
l'url ne sera pas tj redirigé .
et indiquent au client que le document n'a pas été modifié , donc disponible en cache .
- Erreurs 4xx: Coté client
avoir été comprise .
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 ...)
- Erreurs 5xx: Coté server
de proxy , il à reçu une requette incorrecte .
de maintenance ou pour cause de surcharge de requettes .
Les Champs d'entête :
=-=-=-=-=-=-=-=-=-=-=
Légende :
+ 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
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 .
mail du client , et qui peut être un outil de suivi pour les admin ... mais bon , il
est praticment pas utilisé ...
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 .
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é !
ainsi que sur le navigateur choisit , cependant c'est un mouchard servant à des buts
statistiques , puisque n'importe quel information peut être mise dedans .
réponse de server est 401 (non autorisé).
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 .
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
- Protocole http - mise à jour
- Mise à jour sybase - Conseils pratiques -SQL
- Télécharger mise à jour delphi ds150e gratuit - Forum Delphi / Pascal
- L'opération doit utiliser une requête qui peut être mise à jour - Forum VB.NET
- Installation Delphi ✓ - Forum Delphi / Pascal
- Http w3javascript.com - Forum C / C++ / C++.NET
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.