Introduction à la programmation WEB en JAVA - Servlets et pages JSP -
Introduction
Ce document est un support de cours : ce n'est pas un cours complet. Des approfondissements nécessitent l'aide d'un enseignant et par ailleurs un certain nombre de thèmes n'ont pas été abordés.
L'étudiant y trouvera cependant des informations lui permettant la plupart du temps de travailler seul. Il comporte peut-être encore des erreurs : toute suggestion constructive est la bienvenue à l'adresse .
Beaucoup d'informations de ce polycopié sont tirées de la référence 1 dont le contenu (1000 pages) dépasse très largement celui de de polycopié.
S'il est suffisant pour une introduction à la programmation web en Java, ce document pourrait être amélioré en y ajoutant les thèmes importants suivants :
Serge Tahé Septembre 2002
Dans ce chapitre, nous présentons les bases de la programmation Web. Il a pour but essentiel de faire découvrir les grands principes de la programmation Web avant de mettre ceux-ci en pratique avec un langage et un environnement particuliers. Il présente de nombreux exemples qu'il est conseillé de tester afin de "s'imprégner" peu à peu de la philosophie du développement web.
1.1 |
Les composantes d'une application Web |
Numéro Rôle Exemples courants |
|||
OS Serveur |
Linux, Windows |
||
Serveur Web |
Apache (Linux, Windows) IIS (NT), PWS(Win9x) |
||
|
Scripts exécutés côté serveur. Ils peuvent l'être par des modules du serveur ou par des programmes externes au serveur (CGI). |
PERL (Apache, IIS, PWS) VBSCRIPT (IIS,PWS) JAVASCRIPT (IIS,PWS) PHP (Apache, IIS, PWS) JAVA (Apache, IIS, PWS) C#, (IIS) |
|
Base de données - Celle-ci peut être sur la même machine que le programme qui l'exploite ou sur une autre via Internet. |
Oracle (Linux, Windows) MySQL (Linux, Windows) Access (Windows) SQL Server (Windows) |
||
OS Client |
Linux, Windows |
Navigateur WebNetscape, Internet Explorer
Scripts exécutés côté client au sein du navigateur. Ces scripts n'ont aucun accès aux VBscript (IE)
disques du poste client.Javascript (IE, Netscape)
Perlscript (IE)
Applets JAVA
1.2 |
Les échanges de données dans une application web avec formulaire |
Numéro Rôle |
||||
Le navigateur demande une URL pour la 1ère fois (http://machine/url). Auncun paramètre n'est passé. |
||||
Le serveur Web lui envoie la page Web de cette URL. Elle peut être statique ou bien dynamiquement générée par un script serveur (SA) qui a pu utiliser le contenu de bases de données (SB, SC). Ici, le script détectera que l'URL a été demandée sans passage de paramètres et génèrera la page WEB initiale. Le navigateur reçoit la page et l'affiche (CA). Des scripts côté navigateur (CB) ont pu modifier la page initiale envoyée par le serveur. Ensuite par des interactions entre l'utilisateur (CD) et les scripts (CB) la page Web va être modifiée. Les formulaires vont notamment être remplis. |
||||
L'utilisateur valide les données du formulaire qui doivent alors être envoyées au serveur web. Le navigateur redemande l'URL initiale ou une autre selon les cas et transmet en même temps au serveur les valeurs du formulaire. Il peut utiliser pour ce faire deux méthodes appelées GET et POST. A réception de la demande du client, le serveur déclenche le script (SA) associé à l'URL demandée, script qui va détecter les paramètres et les traiter. |
||||
Le serveur délivre la page WEB construite par programme (SA, SB, SC). Cette étape est identique à l'étape 2 précédente. Les échanges se font désormais selon les étapes 2 et 3. |
||||
1.3 |
Quelques ressources |
|||
Ci-dessous on trouvera une liste de ressources permettant d'installer et d'utiliser certains outils permettant de faire du développement web. On trouvera en annexe, une aide à l'installation de ces outils.
- Apache, Installation et Mise en œuvre, O'Reilly
- Programmation en Perl, Larry Wall, O'Reilly
- Applications CGI en Perl, Neuss et Vromans, O'Reilly
- la documentation HTML livrée avec Active Perl
- Prog. Web avec PHP, Lacroix, Eyrolles
- Manuel d'utilisation de PHP récupérable sur le site de PHP
?/scripting/vbscript
- Interface entre WEB et Base de données sous WinNT, Alex Homer, Eyrolles
- JAVA Servlets, Jason Hunter, O'Reilly
- Programmation réseau avec Java, Elliotte Rusty Harold, O'Reilly
- JDBC et Java, George Reese, O'reilly
- Le manuel de MySQL est disponible sur le site de MySQL
- Oracle 8i sous Linux, Gilles Briard, Eyrolles
- Oracle 8i sous NT, Gilles Briard, Eyrolles
1.4 |
Notations |
Dans la suite, nous supposerons qu'un certain nombre d'outils ont été installés et adopterons les notations suivantes :
notation |
signification |
racine de l'arborescence du serveur apache |
|
racine des pages Web délivrées par Apache. C'est sous cette racine que doivent se trouver les pages Web. Ainsi l'URL correspond au fichier \. |
|
racine de l'arborescence lié à l'alias cgi-bin et où l'on peut placer des scripts CGI pour Apache. Ainsi l'URL correspond au fichier \. |
racine des pages Web délivrées par PWS. C'est sous cette racine que doivent se trouver les pages Web. Ainsi l'URL correspond au fichier \. racine de l'arborescence du langage Perl. L'exécutable se trouve en général dans \bin. racine de l'arborescence du langage PHP. L'exécutable se trouve en général dans . racine de l'arborescence de java. Les exécutables liés à java se trouvent dans \bin.
racine du serveur Tomcat. On trouve des exemples de servlets dans \webapps\examples\servlets et des exemples de pages JSP dans \webbapps\examples\jsp
On se reportera pour chacun de ces outils à l'annexe qui donne une aide pour leur installation.
1.5 |
Pages Web statiques, Pages Web dynamiques |
Une page statique est représentée par un fichier HTML. Une page dynamique est, elle, générée "à la volée" par le serveur web. Nous vous proposons dans ce paragraphe divers tests avec différents serveurs web et différents langages de programmation afin de montrer l'universalité du concept web.
1.5.1 Page statique HTML (HyperText Markup Language)
Considérons le code HTML suivant :
essai 1 : une page statique
Une page statique
qui produit la page web suivante :
Les tests
- lancer le serveur Apache
- mettre le script dans
- visualiser l’URL avec un navigateur - arrêter le serveur Apache
- lancer le serveur PWS
- mettre le script dans
- visualiser l’URL avec un navigateur
1.5.2 Une page ASP (Active Server Pages)
Le script :
essai 1 : une page asp
Une page asp générée dynamiquement par le serveur PWS
Il est <% =time %>
A chaque fois que vous rafraîchissez la page, l'heure change.
produit la page web suivante :
Le test
- lancer le serveur PWS
- mettre le script dans
- demander l’URL avec un navigateur
1.5.3 Un script PERL (Practical Extracting and Reporting Language)
Le script :
#!d:\perl\bin\
($secondes,$minutes,$heure)=localtime(time);
print <
Content-type: text/html
essai 1 : un script Perl
Une page générée dynamiquement par un script Perl
Il est $heure:$minutes:$secondes
A chaque fois que vous rafraîchissez la page, l'heure change.
HTML
;
La première ligne est le chemin de l'exécutable . Il faut l'adapter si besoin est. Une fois exécuté par un serveur Web, le script produit la page suivante :
Le test
- serveur Web : Apache
- pour information, visualisez le fichier de configuration ou selon la version d'Apache dans \confs et rechercher la ligne parlant de cgi-bin afin de connaître le répertoire dans lequel placer . - mettre le script dans
- demander l’url
A noter qu’il faut davantage de temps pour avoir la page perl que la page asp. Ceci parce que le script Perl est exécuté par un interpréteur Perl qu’il faut charger avant qu’il puisse exécuter le script. Il ne reste pas en permanence en mémoire.
1.5.4 Un script PHP (Personal Home Page)
Le script
essai 4 : une page php Une page PHP générée dynamiquement A chaque fois que vous rafraîchissez la page, l'heure change. |
Le script précédent produit la page web suivante :
Les tests
- consulter le fichier de configuration ou d'Apache dans \confs
- pour information, vérifier les lignes de configuration de php
- lancer le serveur Apache
- mettre dans
- demander l’URL
- lancer le serveur PWS
- pour information, vérifier la configuration de PWS à propos de php
- mettre dans \php - demander l'URL
1.5.5 Un script JSP (Java Server Pages)
Le script
<% //programme Java affichant l'heure %>
<%@ page import=".*" %>
<% // code JAVA pour calculer l'heure Calendar calendrier=Calendar.getInstance(); int (Calendar.HOUR_OF_DAY); int (Calendar.MINUTE); int (Calendar.SECOND); // heures, minutes, secondes sont des variables globales // qui pourront être utilisées dans le code HTML %> <% // code HTML %> Page JSP affichant l'heure Une page JSP générée dynamiquement Il est <%=heures%>:<%=minutes%>:<%=secondes%> A chaque fois que vous rechargez la page, l'heure change |
Une fois exécuté par le serveur web, ce script produit la page suivante :
Les tests
1.5.6 Conclusion
Les exemples précédents ont montré que :
- une page HTML pouvait être générée dynamiquement par un programme. C'est tout le sens de la programmation Web.
- que les langages et les serveurs web utilisés pouvaient être divers. Actuellement on observe les grandes tendances suivantes:
o les tandems Apache/PHP (Windows, Linux) et IIS/PHP (Windows) o la technologie sur les plate-formes Windows qui associent le serveur IIS à un langage .NET (C#,
, ) o la technologie des servlets Java et pages JSP fonctionnant avec différents serveurs (Tomcat, Apache, IIS) et sur différentes plate-formes (Windows, Linux). C'est cette denière technologie qui sera plus particulièrement développée dans ce document.
1.6 |
Scripts côté navigateur |
Une page HTML peut contenir des scripts qui seront exécutés par le navigateur. Les langages de script côté navigateur sont nombreux. En voici quelques-uns :
Langage |
Navigateurs utilisables |
Vbscript |
IE |
Javascript |
IE, Netscape |
PerlScript |
IE |
Java |
IE, Netscape |
Prenons quelques exemples.
1.6.1 Une page Web avec un script Vbscript, côté navigateur
La page
essai : une page web avec un script vb |
|
Une page Web avec un script VB |
Cliquez sur le bouton |
La page HTML ci-dessus ne contient pas simplement du code HTML mais également un programme destiné à être exécuté par le navigateur qui aura chargé cette page. Le code est le suivant :
Les balises servent à délimiter les scripts dans la page HTML. Ces scripts peuvent être écrits dans différents langages et c'est l'option language de la balise
Une page Web avec un script Javascript
Cliquez sur le bouton
On a là quelque chose d'identique à la page précédente si ce n'est qu'on a remplacé le langage VBScript par le langage Javascript. Celui-ci présente l'avantage d'être accepté par les deux navigateurs IE et Netscape. Son exécution donne les mêmes résultats :
Les tests
- serveur Apache
- script dans
- demander l’url avec le navigateur IE ou Netscape
- serveur PWS
- script dans
- demander l’url avec le navigateur IE ou Netscape
1.7 |
Les échanges client-serveur |
Revenons à notre schéma de départ qui illustrait les acteurs d'une application web :
Nous nous intéressons ici aux échanges entre la machine cliente et la machine serveur. Ceux-ci se font au travers d'un réseau et il est bon de rappeler la structure générale des échanges entre deux machines distantes.
1.7.1 Le modèle OSI
Le modèle de réseau ouvert appelé OSI (Open Systems Interconnection Reference Model) défini par l'ISO (International Standards Organisation) décrit un réseau idéal où la communication entre machines peut être représentée par un modèle à sept couches :
|-------------------------------------|
7 | Application |
|-------------------------------------|
6 | Présentation |
|-------------------------------------|
5 | Session |
|-------------------------------------|
4 | Transport |
|-------------------------------------|
3 | Réseau |
|-------------------------------------|
2 | Liaison |
|-------------------------------------|
1 | Physique |
|-------------------------------------|
Chaque couche reçoit des services de la couche inférieure et offre les siens à la couche supérieure. Supposons que deux applications situées sur des machines A et B différentes veulent communiquer : elles le font au niveau de la couche Application. Elles n'ont pas besoin de connaître tous les détails du fonctionnement du réseau : chaque application remet l'information qu'elle souhaite transmettre à la couche du dessous : la couche Présentation. L'application n'a donc à connaître que les règles d'interfaçage avec la couche Présentation. Une fois l'information dans la couche Présentation, elle est passée selon d'autres règles à la couche Session et ainsi de suite, jusqu'à ce que l'information arrive sur le support physique et soit transmise physiquement à la machine destination. Là, elle subira le traitement inverse de celui qu'elle a subi sur la machine expéditeur.
A chaque couche, le processus expéditeur chargé d'envoyer l'information, l'envoie à un processus récepteur sur l'autre machine apartenant à la même couche que lui. Il le fait selon certaines règles que l'on appelle le protocole de la couche. On a donc le schéma de communication final suivant :
Machine A Machine B
+-------------------------------------+ +----------------------------+
7 ¦ Application v ¦ ¦ ^ Application ¦
+------------------------Î------------¦ +-----Î----------------------¦
6 ¦ Présentation v ¦ ¦ ^ Présentation ¦
+------------------------Î------------¦ +-----Î----------------------¦
5 ¦ Session v ¦ ¦ ^ Session ¦
+------------------------Î------------¦ +-----Î----------------------¦
4 ¦ Transport v ¦ ¦ ^ Transport ¦
+------------------------Î------------¦ +-----Î----------------------¦
3 ¦ Réseau v ¦ ¦ ^ Réseau ¦
+------------------------Î------------¦ +-----Î----------------------¦
2 ¦ Liaison v ¦ ¦ ^ Liaison ¦
+------------------------Î------------¦ +-----Î----------------------¦
1 ¦ Physique v ¦ ¦ ^ Physique ¦
+------------------------Î------------+ +-----Î----------------------+
¦ ^
+-->------->------>-----+
Le rôle des différentes couches est le suivant :
Assure la transmission de bits sur un support physique. On trouve dans cette couche des équipements terminaux de traitement des données (E.T.T.D.) tels que terminal ou ordinateur, ainsi que des équipements de terminaison de circuits de données (E.T.C.D.) tels que modulateur/démodulateur, multiplexeur, concentrateur. Les points d'intérêt à ce niveau sont :
. le choix du codage de l'information (analogique ou numérique) . le choix du mode de transmission (synchrone ou asynchrone).
Masque les particularités physiques de la couche Physique. Détecte et corrige les erreurs de transmission.
Gère le chemin que doivent suivre les informations envoyées sur le réseau. On appelle cela le routage : déterminer la route à suivre par une information pour qu'elle arrive à son destinataire.
Permet la communication entre deux applications alors que les couches précédentes ne permettaient que la communication entre machines. Un service fourni par cette couche peut être le multiplexage : la couche transport pourra utiliser une même connexion réseau (de machine à machine) pour transmettre des informations appartenant à plusieurs applications.
On va trouver dans cette couche des services permettant à une application d'ouvrir et de maintenir une session de travail sur une machine distante.
Elle vise à uniformiser la représentation des données sur les différentes machines. Ainsi des données provenant d'une machine A, vont être "habillées" par la couche Présentation de la machine A, selon un format standard avant d'être envoyées sur le réseau. Parvenues à la couche Présentation de la machine destinatrice B qui les reconnaîtra grâce à leur format standard, elles seront habillées d'une autre façon afin que l'application de la machine B les reconnaisse.
A ce niveau, on trouve les applications généralement proches de l'utilisateur telles que la messagerie électronique ou le transfert de fichiers.
1.7.2 Le modèle TCP/IP
Le modèle OSI est un modèle idéal. La suite de protocoles TCP/IP s'en approche sous la forme suivante :
+----------------+ +---------------------------+
¦ Application ¦ ¦ Application ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ +---------------------------+
¦ Transport ¦ ¦ Transport ¦
¦ (Udp/Tcp) ¦ ¦ (Udp/tcp) ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ ou +---------------------------+
¦ Réseau (IP) ¦ segments (TCP) ¦ Réseau (IP) ¦
+----------------+ +---------------------------+
¦ ¦
+----------------+ +----------------------------+
¦Interface réseau¦ ¦ Interface réseau ¦
+-------Ê--------+ +----------------------------+
¦ ¦
+----------------------------------------------+ réseau physique
- l'interface réseau (la carte réseau de l'ordinateur) assure les fonctions des couches 1 et 2 du modèle OSI
- la couche IP (Internet Protocol) assure les fonctions de la couche 3 (réseau)
- la couche TCP (Transfer Control Protocol) ou UDP (User Datagram Protocol) assure les fonctions de la couche 4 (transport). Le protocole TCP s'assure que les paquets de données échangés par les machines arrivent bien à destination. Si ce n'est pas les cas, il renvoie les paquets qui se sont égarés. Le protocole UDP ne fait pas ce travail et c'est alors au développeur d'applications de le faire. C'est pourquoi sur l'internet qui n'est pas un réseau fiable à 100%, c'est le protocole TCP qui est le plus utilisé. On parle alors de réseau TCP-IP.
- la couche Application recouvre les fonctions des niveaux 5 à 7 du modèle OSI.
Les applications web se trouvent dans la couche Application et s'appuient donc sur les protocoles TCP-IP. Les couches Application des machines clientes et serveur s'échangent des messages qui sont confiées aux couches 1 à 4 du modèle pour être acheminées à destination. Pour se comprendre, les couches application des deux machines doivent "parler" un même langage ou protocole. Celui des applications Web s'appelle HTTP (HyperText Transfer Protocol). C'est un protocole de type texte, c.a.d. que les machines échangent des lignes de texte sur le réseau pour se comprendre. Ces échanges sont normalisés, c.a.d. que le client dispose d'un certain nombre de messages pour indiquer exactement ce qu'il veut au serveur et ce dernier dispose également d'un certain nombre de messages pour donner au client sa réponse. Cet échange de messages a la forme suivante :
ligne vide |
Client --> Serveur
Lorsque le client fait sa demande au serveur web, il envoie
Serveur --> Client
Lorsque le serveur fait sa réponse au client, il envoie
Les échanges ont donc la même forme dans les deux sens. Dans les deux cas, il peut y avoir envoi d'un document même s'il est rare qu'un client envoie un document au serveur. Mais le protocole HTTP le prévoit. C'est ce qui permet par exemple aux abonnés d'un fournisseur d'accès de télécharger des documents divers sur leur site personnel hébergé chez ce fournisseur d'accès. Les documents échangés peuvent être quelconques. Prenons un navigateur demandant une page web contenant des images :
1.7.3 Le protocole HTTP
Découvrons le protocole HTTP sur des exemples. Que s'échangent un navigateur et un serveur web ?
1.7.3.1 La réponse d'un serveur HTTP
Nous allons découvrir ici comment un serveur web répond aux demandes de ses clients. Le service Web ou service HTTP est un service TCP-IP qui travaille habituellement sur le port 80. Il pourrait travailler sur un autre port. Dans ce cas, le navigateur client serait obligé de préciser ce port dans l'URL qu'il demande. Une URL a la forme générale suivante :
protocole://machine[:port]/chemin/infos avec
protocolehttp pour le service web. Un navigateur peut également servir de client à des services ftp, news, telnet, ..
machinenom de la machine où officie le service web portport du service web. Si c'est 80, on peut omettre le n° du port. C'est le cas le plus fréquent cheminchemin désignant la ressource demandée
infosinformations complémentaires données au serveur pour préciser la demande du client
Que fait un navigateur lorsqu'un utilisateur demande le chargement d'une URL ?
Pour découvrir les échanges entre un client et un serveur web, nous allons utiliser un client TCP générique. C'est un programme qui peut être client de tout service ayant un protocole de communication à base de lignes de texte comme c'est le cas du protocole HTTP. Ces lignes de texte seront tapées par l'utilisateur au clavier. Cela nécessite qu'il connaisse le protocole de communication du service qu'il cherche à atteindre. La réponse du serveur est ensuite affichée à l'écran. Le programme a été écrit en Java et on le trouvera en annexe. On l'utilise ici dans une fenêtre Dos sous windows et on l'appelle de la façon suivante :
java clientTCPgenerique machine port avec
machinenom de la machine où officie le service à contacter portport où le service est délivré
Avec ces deux informations, le programme va ouvrir une connexion TCP-IP avec la machine et le port désignés. Cette connexion va servir aux échanges de lignes de texte entre le client et le serveur web. Les lignes du client sont tapées par l'utilisateur au clavier et envoyées au serveur. Les lignes de texte renvoyées par le serveur comme réponse sont affichées à l'écran. Un dialogue peut donc s'instaurer directement entre l'utilisateur au clavier et le serveur web. Essayons sur les exemples déjà présentés. Nous avions créé la page HTML statique suivante :
essai 1 : une page statique
Une page statique
que nous visualisons dans un navigateur :
On voit que l'URL demandée est : . La machine du service web est donc localhost (=machine locale) et le port 81. Si on demande à voir le texte HTML de cette page Web (Affichage/Source) on retrouve le texte HTML initialement créé :
Maintenant utilisons notre client TCP générique pour demander la même URL :
Dos>java clientTCPgenerique localhost 81
Commandes :
GET HTTP/1.0
<--
essai 1 : une page statique
Une page statique
Au lancement du client par la commande java clientTCPgenerique localhost 81 un tuyau a été créé entre le programme et le serveur web opérant sur la même machine (localhost) et sur le port 81. Les échanges client-serveur au format HTTP peuvent commencer. Rappelons que ceux-ci ont trois composantes :
Dans notre exemple, le client n'envoie qu'une demande:
GET HTTP/1.0
Cette ligne a trois composantes :
commande HTTP pour demander une ressource. Il en existe d'autres :
HEAD demande une ressource mais en se limitant aux entêtes HTTP de la réponse du serveur. La ressource elle-même n'est pas envoyée.
PUT permet au client d'envoyer un document au serveur
ressource demandée
HTTP/1.0 niveau du protocole HTTP utilisé. Ici le 1.0. Cela signifie que le serveur fermera la connexion dès qu'il aura envoyé sa réponse
Les entêtes HTTP doivent toujours être suivis d'une ligne vide. C'est ce qui a été fait ici par le client. C'est comme cela que le client ou le serveur sait que la partie HTTP de l'échange est terminé. Ici pour le client c'est terminé. Il n'a pas de document à envoyer. Commence alors la réponse du serveur composée dans notre exemple de toutes les lignes commençant par le signe
le serveur dit
- qu'il comprend le protocole HTTP version 1.1
- qu'il a la ressource demandée (code 200, message OK) la date/heure de la réponse le serveur s'identifie. Ici c'est un serveur Apache
E:\data\serge\web\essais>dir 08/07/2002 10:00 161 |
date de dernière modification de la ressource demandée par le client
unité de mesure des données envoyées. Ici l'octet (byte) nombre de bytes du document qui va être envoyé après les entêtes HTTP. Ce nombre est en fait la taille en octets du fichier :
le serveur dit qu'il fermera la connexion une fois le document envoyé le serveur dit qu'il va envoyer du texte (text) au format HTML (html).
Le client reçoit ces entêtes HTTP et sait maintenant qu'il va recevoir 161 octets représentant un document HTML. Le serveur envoie ces 161 octets immédiatement derrière la ligne vide qui signalait la fin des entêtes HTTP :
essai 1 : une page statique
Une page statique
On reconnaît là, le fichier HTML construit initialement. Si notre client était un navigateur, après réception de ces lignes de texte, il les interpréterait pour présenter à l'utilisateur au clavier la page suivante :
Utilisons une nouvelle fois notre client TCP générique pour demander la même ressource mais cette fois-ci avec la commande HEAD qui demande seulement les entêtes de la réponse :
Dos> clientTCPgenerique localhost 81 Commandes : <-- |
Nous obtenons le même résultat que précédemment sans le document HTML. Notons que dans sa demande HEAD, le client a indiqué qu'il utilisait le protocole HTTP version 1.1. Cela l'oblige à envoyer un second entête HTTP précisant le couple machine:port que le client veut interroger : Host: localhost:81.
Maintenant demandons une image aussi bien avec un navigateur qu'avec le client TCP générique. Tout d'abord avec un navigateur :
Le fichier a 3167 octets :
E:\data\serge\web\images>dir
14/04/2000 13:37 3 167
Utilisons maintenant le client TCP générique :
E:\data\serge\JAVA\SOCKETS\client générique>java clientTCPgenerique localhost 81 Commandes : <-- |
On notera les points suivants dans la réponse du serveur :
- nous ne demandons que les entêtes HTTP de la ressource. En effet, une image est un fichier binaire et non un fichier texte et son affichage à l'écran en tant que texte ne donne rien de lisible.
- c'est la taille du fichier
- le serveur indique à son client qu'il va lui envoyer un document de type image/gif, c.a.d. une image au format GIF. Si l'image avait été au format JPEG, le type du document aurait été image/jpeg. Les types des documents sont standardisés et sont appelés des types MIME (Multi-purpose Mail Internet Extension).
1.7.3.2 La demande d'un client HTTP
Maintenant, posons-nous la question suivante : si nous voulons écrire un programme qui "parle" à un serveur web, quelles commandes doit-il envoyer au serveur web pour obtenir une ressource donnée ? Nous avons dans les exemples précédents obtenu un début de réponse. Nous avons rencontré trois commandes :
- pour demander une ressource donnée selon une version donnée du protocole HTTP. Le serveur envoie une réponse au format HTTP suivie d'une ligne vide suivie de la ressource demandée
- idem si ce n'est qu'ici la réponse se limite aux entêtes HTTP et de la ligne vide
- pour préciser (protocole HTTP 1.1) la machine et le port du serveur web interrogé
Il existe d'autres commandes. Pour les découvrir, nous allons maintenant utiliser un serveur TCP générique. C'est un programme écrit en Java et que vous trouverez lui aussi en annexe. Il est lancé par : java serveurTCPgenerique portEcoute, où portEcoute est le port sur lequel les clients doivent se connecter. Le programme serveurTCPgenerique
- affiche à l'écran les commandes envoyées par les clients
- leur envoie comme réponse les lignes de texte tapées au clavier par un utilisateur. C'est donc ce dernier qui fait office de serveur. Dans notre exemple, l'utilisateur au clavier jouera le rôle d'un service web.
Simulons maintenant un serveur web en lançant notre serveur générique sur le port 88 :
Dos> |
java serveurTCPgenerique 88 |
|
Serveur générique lancé sur le port 88 |
Prenons maintenant un navigateur et demandons l'URL . Le navigateur va alors se connecter sur le port 88 de la machine localhost puis demander la page :
Regardons maintenant la fenêtre de notre serveur qui affiche ce que le client lui a envoyé (certaines lignes spécifiques au fonctionnement du programme serveurTCPgenerique ont été omises par souci de simplification) :
Dos>java serveurTCPgenerique 88 Serveur générique lancé sur le port 88 914) <-- |
Les lignes précédées du signe
- liste de types MIME de documents que le navigateur sait traiter.
- la langue acceptée de préférence pour les documents.