I. Introduction▲
Dans cette note technique, nous vous proposons un outil de test et de contrôle des serveurs web fait en 4D et le plug-in 4D Internet commands. 4D Webtools est un outil qui vous sera de grande utilité aussi bien pendant la phase de développement que pour contrôler les serveurs Web en production. Nous commencerons dans cette note par introduire le plug-in 4D Internet commands et son approche bas niveau. Ensuite, nous présenterons des notions fondamentales sur le protocole, les requêtes et les réponses http, indispensables pour la compréhension du fonctionnement de cet outil. Enfin nous décrirons le fonctionnement de la base de démo.
II. Le plug-in 4D Internet commands et son approche bas niveau▲
Les Internet Commands est un plugin 4D gratuit qui doit être copié dans le dossier Mac4dx sous MacOs et dans le dossier Win4dx sous Windows. Ces dossiers peuvent être placés dans deux emplacements différents : d’abord à côté de la structure de la base de données dans ce cas le plugin sera disponible uniquement pour la base de données en question, ou dans le dossier de l’application 4D ou 4D serveur pour être disponible pour toutes les bases ouvertes par cette application. La documentation du plugin, disponible en deux langues française et anglaise, est très complète et comporte plusieurs exemples bien commentés. Les routines des ICs sont des fonctions qui renvoient un entier. Si la routine s’exécute correctement la valeur retournée est égale à zéro. Dans le cas contraire, un code d’erreur est retourné.
Pour pouvoir utiliser les Internet commands il faut disposer d’une couche IP active sur la machine. Étant donné que les IC n’utilisent pas les composants réseau TCP/IP de 4D, la commande IT_MacTCPinit permettant d’initialiser le gestionnaire TCP doit être appelée avant toute autres routines. Contrairement à ce que son nom l’indique, cette commande doit être appelée aussi bien sous Mac que sous Windows.
Les ICs offre la possibilité d’utiliser l’approche bas niveau en proposant un certain nombre de routines préfixées par « TCP_ ». Ces routines vont nous permettre de :
- ouvrir et fermer une connexion (TCP_Open ,TCP_Close) ;
- envoyer ou recevoir des données (TCP_Send, TCP_SendBLOB, TCP_Receive, TCP_ReceiveBLOB) ;
- se mettre en attente d’une connexion entrante (TCP_Listen) ;
- connaître le statut d’une connexion (TCP_State).
Le principe de cette note technique est simple et consiste à établir une connexion avec un serveur Web et de lui demander une page HTML ou autre type de document (image, vidéo, pdf…). La réponse à notre requête sera reçue dans un BLOB. Il est ensuite de notre ressort de parcourir le BLOB, après l’avoir converti en texte, pour en extraire les données par analyse des balises HTML et séparer le corps et l’entête de la réponse.
Plus concrètement, cette interrogation du serveur web peut être décrite par la séquence suivante :
- uuverture de la connexion avec TCP_Open ;
- envoi d’une requête http par la routine TCP_Send ;
- réception des données dans un BLOB par la routine TCP_RceiveBLOB avec contrôle de l’état de la connexion par la routine TCP_State ;
- enfin fermeture de la connexion par la routine TCP_Close.
Il est important de noter qu’à partir de la version 681 des ICs, la commande TCP_Open permet d’ouvrir des connexions sécurisées et de choisir si le Scheduler de 4D continue d’être appelé au cours de la session (Mode asynchrone ou synchrone) :
TCP_Open (Nom Serveur; Port Distant; TCP_ID{ ; Paramètres Session}) -> Code d’erreur
Avec :
Nom Serveur : (Alpha) correspond au Nom ou adresse IP du serveur
Port Distant : (Entier) correspond au Port distant auquel se connecter (0 = indifférent)
TCP_ID : (Entier long) correspond à la référence de la session TCP ouverte
Paramètres Session : (Entier) correspond au Paramètre de la session TCP (0,1,2 ou 3)
0 = Synchrone (valeur par défaut si omis)
1 = Asynchrone
2 = Utilisation SSL, synchrone
3 = Utilisation SSL, asynchrone
Code d’erreur : (Entier)
Le paramètre Paramètres Session permet de choisir les paramètres de la Session TCP qui seront appliqués à chaque commande TCP tout au long de la session. Sa valeur par défaut est 0 (Synchrone sans SSL). En mode asynchrone, le Scheduler 4D prend la main sans attendre que les processus de connexion en cours soient finis. En revanche, en mode synchrone le Scheduler 4D reprend le contrôle uniquement lorsque le processus de connexion est terminé. L’erreur 10089 est retournée lorsque l’on passe le paramètre 2 ou 3 et que la connexion SSL ne peut être ouverte (par exemple si le 4DSLI.DLL n’est pas chargé). Par conséquent, pour se connecter à un site en https il faudra s’assurer que ce DLL est correctement installé puis ouvrir une connexion en utilisant le numéro de port 443 :
$Erreur := TCP_Open (Nom Serveur; 443; TCP_ID;2).
III. Utilisation du protocole HTTP▲
Les messages échangés entre notre base de données et le serveur Web ne sont que des requêtes et des réponses http. Le protocole HTTP (HyperText Transfer Protocol) est un protocole sans état et rapide permettant le transfert de données, au-dessus d’un protocole type TCP. Il est basé sur la notion de Requête/Réponse. Un client établit une connexion avec un serveur, envoie une requête au serveur sous la forme d’une méthode, une URL (ou URI d’une façon générale Uniform Resource Identifier RFC 1738 et 1808) et une version du protocole suivie d’un ensemble de modificateurs et éventuellement un corps de message. Le serveur répond sous la forme d’une ligne, dite de statut, indiquant la version du protocole et un code de succès ou d’échec, suivie de modificateurs contenant des informations relatives au serveur et au corps éventuel du message. Une fois la réponse retournée, le serveur ferme la connexion. Cette communication se passe en général au-dessus d’une connexion TCP, le port par défaut est le port 80 en http et 443 en https (communication sécurisée).
Les requêtes HTTP▲
Dans notre cas le plug-in 4D Internet Commands envoie une requête de document qui consiste en une ligne écrite en caractères ASCII se terminant par « CR LF » « Retour chariot + Fin de ligne » c’est-à-dire « Caractere(13) + Caractere(10) » dans le langage 4D. Cette requête dans le cas le plus simple est du type « GET », un espace et l’adresse du document, mais la syntaxe générale d’une requête est du type :
Requête = Commande <URL> Version_Du_Protocole <CR, LF>
[Entêtes]
<CR, LF>
[Corps_De_La_Requête]
La version de Version_Du_Protocole est HTTP/1.0 ou HTTP/1.1 et URL est la chaîne identifiant l’objet sur l’Internet.
Les principales commandes d’une requête http sont :
|
GET |
Demande l’envoi des données identifiées par l’URL. |
|
POST |
Permet l’envoi des données d’un formulaire. |
|
HEAD |
Identique à GET, mais retourne seulement les entêtes HTTP sans le corps du document. |
|
PUT |
Transmet un fichier au serveur. |
Post ou Get
La différence entre ces deux types de requêtes réside dans la façon suivant laquelle le navigateur web envoie les données du formulaire et la quantité des données que ce formulaire pourrait contenir. Pour le GET, les champs du formulaire sont packagés et envoyés sous la forme d’une seule URL. Généralement, il n’y a pas une longueur limite de l’URL formée, mais certains navigateurs web la limitent à 1 k octets environ. Dans le cas d’un POST, les champs du formulaire Web sont également packagés, mais envoyés à la fin de la requête http. Il n’y a, également, pas de longueur limite pour les données envoyées, mais certains navigateurs la limitent quand même à 6 k octets caractères maximum par zone de texte. Il est également important de noter qu’il n’y a que le POST qui permet d’envoyer (Upload) un document via le Web (pas le GET).
HEAD et PUT dans 4D
Dans les versions actuelles le serveur Web 4D ne supporte pas la commande PUT et supporte partiellement la commande HEAD. Par exemple, en interrogeant via la commande HEAD un serveur web sur Internet autre que 4D on obtient une réponse comme ci-dessous :
Alors qu’avec un serveur Web 4D 2003 on obtient ce qui suit :
Par ailleurs, on peut personnaliser notre requête en lui ajoutant des entêtes permettant de fournir des informations plus précises au serveur Web. En pratique il existe une cinquantaine d’entêtes possibles des requêtes et qui ont toutes le format « Mot-clé : Valeur ». On peut citer parmi les plus utilisées :
|
From |
Adresse mail de l’utilisateur |
|
If-modified-since |
La page n’est transférée que si elle a été modifiée depuis la date précisée |
|
Referer |
URL d’origine de la page contenant le lien à partir duquel le navigateur a trouvé l’URL |
|
User-agent |
Précise le nom et la version du navigateur |
|
Accept |
Types MIME visualisables par le navigateur |
Voici un exemple de requête :
GET /index.html HTTP/1.0
Accept : text/html
User-Agent : Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Les réponses HTTP▲
La réponse envoyée par le serveur web se compose d’une première ligne précisant la version du protocole, un code (ou statut) de réponse et un message précisant la réponse. Suivent éventuellement des entêtes (avec le même format que pour la requête), une ligne vide et le corps de la réponse. On peut présenter une réponse de la manière suivante :
Réponse = HTTP/<Version> <Status> <Commentaire Status>
[< Champ d’entête >: <Valeur>]
Ligne blanche
Document
A chaque réponse du serveur Web correspond un code ou statut d’erreur ou de succès. Le tableau suivant récapitule l’ensemble de ces codes :
|
Code |
Type |
Signification |
|---|---|---|
|
1xx |
Informationnel |
La commande a été reçue – le traitement est en cours. |
|
2xx |
Succès |
La commande a été reçue correctement, comprise et acceptée. |
|
3xx |
Redirection |
La commande ne peut pas être exécutée telle quelle ; il faudra faire autre chose pour la gérer totalement (par exemple aller chercher le document ailleurs) |
|
4xx |
Erreur client |
La commande n’est pas correcte syntaxiquement ou ne peut pas être traitée. |
|
5xx |
Erreur serveur |
Le serveur n’a pu traiter correctement une commande apparemment correcte. |
Types de code de réponse
Ci-dessous un exemple de réponse d’un serveur Web 4D 2003 :
HTTP/1.0 200 OKServer: 4D_WebStar_D/7.3
MIME-Version : 1.0
Content-type : text/html
Content-length : 1055
Date: Wed, 28 Jan 2004 19:43:27 GMT
Last-Modified: Tue, 14 Sep 1999 08:12:52 GMT
<HTML>
<HEAD>
<TITLE>
Exemple de document HTML
</TITLE>
</HEAD>
<BODY>
(Corps du document)
</BODY>
</HTML>IV. Fonctionnement de la base de démo▲
La base exemple traduisant 4D Webtools est composée de deux dialogues principaux. Le premier permet de lancer un projet complet de test d’un serveur Web et le deuxième propose une requête simple, mais complètement paramétrable.
Lancer un projet de test▲
Un projet de test permet d’une part de contrôler le fonctionnement d’un serveur Web ainsi que de tester sa montée en charge en le bombardant par un certain nombre de requêtes prédéfinies. Le dialogue suivant propose à l’utilisateur un projet de test à paramétrer :
Les paramètres d’un projet de test sont les suivants :
- adresse du serveur Web : dans cette zone il faudra saisir l’adresse du serveur web soit en passant l’adresse littérale du site par exemple « www.4d.fr » ou bien son adresse IP ;
- numéro du port serveur Web : le numéro de port par défaut pour le protocole http est le 80, mais ceci peut bien évidemment changer selon la configuration utilisée ;
- utilisation du proxy : ce paramètre nous permet de s’adresser au proxy lorsqu’on ne peut pas se connecter à l’Internet directement. C’est le cas par exemple d’un réseau d’entreprise. Dans ce cas de figure, il convient à l’utilisateur de cocher la case « Passer par le proxy » et saisir l’adresse exacte du proxy dans la zone de saisie qui s’active ;
- communication sécurisée ou non sécurisée : Il s’agit de choisir entre le protocole sécurisé https ayant le numéro de port par défaut 443 et celui non sécurisé http avec le numéro de port par défaut 80 ;
- nombre de Users : Il s’agit du nombre de clients web lancés par la base de démo. En effet, pour chaque client web correspondra un process 4D qui fera tourner la méthode projet HTTP_Multi_Requetes ;
- nombre de requêtes par secondes : cette valeur correspond au nombre de requêtes envoyées par secondes au serveur web. Les process 4D traduisant les clients web seront endormis plus ou moins longtemps en fonction de la valeur donnée à cette propriété ;
- liste des URL : c’est une zone de texte où on doit saisir, à raison d’un par ligne, toutes les URL à envoyer au serveur web. La méthode projet GEN_TexteVersTableau transformera cette variable texte en un tableau texte d’URL et bien entendu toutes les lignes vides seront supprimées ;
- ordre d’envoi des URL : les deux cases à cocher « Dans l’ordre » et « Aléatoirement » permettent de définir l’ordre d’envoi des URL respectivement dans l’ordre ou aléatoirement ;
- bouton « Enregistrer le projet » permet de stocker tous les paramètres d’un projet sur disque sous forme d’un fichier texte. L’enregistrement des projets est assuré par la méthode GEN_Vars_vers_Blob et la commande BLOB VERS DOCUMENT ;
- bouton « Charger le projet » fait exactement l’inverse du bouton « Enregistrer le projet » c’est-à-dire charger un projet à partir du disque. Une vérification de la validité du projet est bien entendu effectuée avant chaque chargement de projet. L’ouverture d’un projet existant est assurée par la méthode GEN_Blob_vers_Vars et la commande DOCUMENT VERS BLOB ;
- enfin pour lancer le projet de test il suffit de cliquer sur le bouton « Démarrer » ou utiliser le raccourci clavier SHIFT+D.
Une fois le projet de test défini et lorsque l’on clique sur le bouton « Démarrer », on passe sur la deuxième page du dialogue qui présente en temps réel les résultats des tests. Voici un aperçu des résultats obtenus :
Dans cette page de dialogue, on retrouve en haut de la page les principales informations sur le projet de test en cours. Puis les résultats de chaque client web sont représentés sous forme de tableaux groupés. Enfin, en bas de la page, on affiche les résultats globaux.
Les résultats des tests sont les suivants :
- liste des clients Web (Nom Client Web) : c’est la liste des process 4D qui simulent les clients Web. On suffixe chaque nom par un indice qui nous renseigne sur le numéro de client web ainsi que sur le nombre total.
- nombre des requêtes : La deuxième colonne présente le nombre de requêtes envoyées par chaque client Web. Le nombre total des requêtes est affiché en bas de la liste ;
- données envoyées en octets : La troisième colonne nous donne la taille des données envoyées par chaque client Web. La taille totale des données envoyées est affichée en bas de cette colonne ;
- nombre des réponses : La quatrième colonne présente le nombre de réponses reçues par chaque client Web. Le nombre total des réponses est affiché en bas de la colonne ;
- données reçues en octets : La cinquième colonne nous donne la taille des données reçues par chaque client Web. La taille totale des données reçues est affichée en bas de cette colonne ;
- nombre d’erreurs : La sixième colonne affiche le nombre d’erreurs reçues par chaque client Web. Le nombre total des erreurs est affiché en bas de la colonne ;
- pourcentage d’erreurs : La septième colonne affiche le pourcentage d’erreurs pour chaque client Web. Le pourcentage total des erreurs est affiché en bas de la colonne.
Pour arrêter le test en cours il suffira de cliquer sur le bouton « STOP » ou d’utiliser le raccourci-clavier SHIFT +S.
Utiliser des requêtes simples▲
Le principe dans cette partie est d’établir une connexion avec un serveur Web et de lui demander une page HTML particulière ou tout autre type de document (image, vidéo, pdf…). La réponse à notre requête sera reçue dans un BLOB qui sera converti en texte, pour en extraire les données par analyse des balises HTML. Cette analyse consiste à séparer le continu de la page et l’entête de la réponse pour donner une réponse claire à l’utilisateur sur le déroulement de la requête, les informations reçues et le contenu du document afin de lui donner la possibilité de stocker le document sur le disque ou dans le fichier de données. En ce qui concerne le dernier point et afin de pouvoir stocker le document, il sera indispensable de traiter, en fonction du type MIME reçu et selon la plateforme, l’extension ou le créateur du document.
L’envoi de la requête est également paramétrable. La copie d’écran suivante présente le dialogue de paramétrage d’une requête dans la base de démo :
Vous remarquerez que ces paramètres sont identiques à ceux de la partie précédente, à l’exception des différences suivantes :
- choix de la méthode utilisée : GET, POST ou HEAD. Lorsque l’on choisit la méthode POST la zone de saisie nommée « Data du POST » s’active pour vous permettre de saisir les données du post ;
- URL : on note que dans ce type de test on ne peut saisir qu’une seule URL ;
- progression : une zone de texte appelée « Progression » affichera à l’utilisateur des informations relatives au déroulement de la requête depuis l’ouverture de la connexion jusqu’à sa fermeture ;
- erreur : une zone de texte qui affichera à l’utilisateur les erreurs rencontrées a été rajoutée à droite de la zone progression. Bien entendu, s’il n’y a pas d’erreurs cette zone reste invisible.
Pour lancer le test et passer à la deuxième page du dialogue qui est la page des résultats, il suffit de cliquer sur le bouton « Envoyer ». Cette page de réponse contiendra les informations citées ci-après comme le montre la copie d’écran suivante :
- Statut de la réponse : à chaque réponse du serveur Web correspond un code ou statut d’erreur ou de succès. Pour plus d’informations sur ce sujet, nous vous renvoyons sur la partie III.2 Les réponses HTTP.
- Taille de données reçues : cette information nous informe sur la quantité de données reçue en octets. Cette taille tient compte de l’entête et du corps de la réponse.
- Entête http : Les entêtes http sont affichés sous forme de deux tableaux groupés. Le premier affiche les noms des champs présents dans l’entête et le deuxième tableau affiche leurs valeurs respectives.
- Corps de la réponse : cette zone affiche le contenu de la page reçue. Cette page peut être la page demandée en cas de succès de la requête ou bien la page de réponse du serveur web ou éventuellement du proxy.
Pour avoir une idée plus claire de fonctionnement de la base de démo en voici quelques exemples d’utilisations.
La copie d’écran suivante montre une simple requête construite pour télécharger la page d’accueil du site APPLE. Dans cet exemple on interroge le proxy, car le test était effectué dans un réseau local où le passage par le proxy pour accéder à l’Internet est obligatoire :
Lorsqu’on clique sur le bouton « Envoyer », la requête est envoyée et on passe sur la deuxième page du formulaire qui nous affiche la réponse, comme le montre l’écran suivant :
Ce deuxième exemple a pour but de tester le fonctionnement et la montée en charge d’un serveur web par exemple celui de 4D SA à l’adresse http://www.4d.fr/ . Ce projet de test est défini dans la copie d’écran suivante, notez que vous pouvez enregistrer vos projets sur disque pour pouvoir les réutiliser :
Pour lancer ce projet de test, il suffit de cliquer sur le bouton « Démarrer ». Les résultats sont alors affichés en temps réels sur la deuxième page comme le montre l’écran suivant :
V. Exemple de requête sécurisée avec SSL▲
Pour pouvoir utiliser le protocole SSL pour vos requêtes sécurisées il faut vérifier la présence du fichier 4DSLI.DLL, nécessaire au fonctionnement de SSL, dans le dossier 4D Extensions de votre application (4D, 4D Serveur, 4D Client ou Base compilée avec 4D Engine). En revanche, il n’est pas nécessaire de disposer d’un certificat SSL ou d’activer la case à cocher « Autoriser SSL pour le serveur Web » dans la fenêtre de dialogue des Propriétés de la base.
Par ailleurs, 4D propose deux types d’interfaces de la couche sécurisée (Secured Layer Interface) pour la gestion du SSL : 4DSLI.DLL pour un cryptage 40-bits et 4DSLI128.DLL pour un cryptage 128-bits. 4D peut utiliser indifféremment l’une ou l’autre librairie. Pour utiliser l’interface 128-bits, il faudra :
1- Renommer ou déplacer le fichier 4DSLI.DLL correspondant au cryptage 40-bits du dossier de la base ;
2- Placer le fichier 4DSLI128.DLL dans le dossier de la base ;
3- Renommer le fichier 4DSLI128.DLL en 4DSLI.DLL.
Ci-après un exemple de requête sécurisée utilisant le protocole SSL. Notez le choix du protocole HTTPS.
Le résultat de cette requête sécurisée est présenté dans la copie d’écran suivante. Il important de noter que le nom du protocole retourné dans le statut de la réponse est HTTP et non HTTPS. Ceci n’est pas une erreur, car le protocole de communication utilisé est bien le HTTP. Le HTTPS n’est pas un protocole à part entière, mais une couche de cryptage et décryptage basée sur le protocole HTTP.
VI. Conclusion▲
Dans cette note technique, nous avons présenté 4D Webtools, un outil de test des web serveurs fait en 4D. Il vous permet de tester et contrôler le fonctionnement des Web serveurs en cours de développement ou bien ceux en production. Le principe de fonctionnement de cet outil consiste à définir un projet de test, le lancer et afficher les résultats qui seront actualisés à temps réel. 4D Webtools vous permet de stocker les projets de test sur disque sous format texte. Vous pouvez faire la même chose pour stocker les résultats de vos tests en vous servant uniquement de deux méthodes génériques : GEN_Vars_vers_Blob et GEN_Blob_vers_Vars.
VII. Bases exemples▲
Téléchargez les bases exemples :
base exemple Mac
base exemple Windows