L'objet Request permet d'accéder à l'en-tête et au corps d'une demande HTTP de l'utilisateur. S'il y a un objet ASP intégré que vous devez parfaitement maîtriser, c'est celui-ci puisqu'il vous permet de répondre aux décisions prises par l'utilisateur. L'utilisation de l'objet Request permet de créer de manière dynamique des pages web et d'améliorer l'exécution des actions côté serveur (comme par exemple, mettre à jour une base de données) en fonction des entrées de l'utilisateur.
Fonctionnement de HTTP
Encore quelques instants avant de vous expliquer en détail l'objet Request. Au préalable, cependant, vous devez bien maîtriser les connaissances de base concernant le protocole HTTP. Cette introduction permettra une meilleure compréhension de l'objet Request. Pour les sceptiques, pas de panique. Il ne s'agit que d'une brève présentation du protocole HTTP.
HTTP : un exemple simple
Vous savez probablement déjà que le protocole HTTP est un protocole de "transaction". Le navigateur (le client) envoie une demande au serveur. Le serveur obéit à la demande s'il le peut et renvoie une réponse au client. Le serveur oublie alors tout de la transaction. Le navigateur quant à lui peut ou non s'en souvenir.
HELLOCGI.HTM, une page HTML créée par une application CGI
Pour mieux comprendre l'interaction entre un navigateur web et un serveur, prenons un exemple simple illustrant cet échange. La figure 7.1 montre Netscape Navigator affichant un formulaire très simple, HELLO.HTM, qui invite l'utilisatrice à saisir son nom. Si l'utilisatrice clique sur le bouton Soumettre, une application CGI est invoquée sur un serveur WebSite qui renvoie la page affichée en Figure 7.2. (même si Navigator et WebSite sont utilisés pour cet exemple, l'échange entre un navigateur et un serveur quelconques se déroulera toujours plus ou moins de la même manière. Ainsi, même si cet exemple utilise une application CGI, le cycle demande-réponse HTTP est quasiment le même que celui des applications ASP. Pour plus d'informations sur la conversion du protocole CGI en protocole ASP, voir Annexe B.) Voyons un peu comment le protocole gère cet échange entre le navigateur et le serveur :
Lorsque l'utilisateur a fini de saisir l'URL de HELLO.HTM, Navigator envoie le flux suivant au serveur :
La fonction send figurant dans la liste de sortie suivante est une fonction socket qui envoie un flux dans un socket connecté. Dans la sortie, 73 identifie le socket alors que 179 correspond à la valeur renvoyée par la fonction et représente le nombre total d'octets envoyés.
Il s'agit d'un en-tête de demande. Le navigateur indique qu'il souhaite que le serveur reçoive le document /HELLO.HTM. Get représente bien plus qu'une simple description générique de ce que le serveur doit faire ; elle indique le type de demande HTTP. (Pour plus de détails, voir Section 7.1.2, ci-après dans le présent chapitre). Le navigateur indique également qu'il utilise une version 1.0 du protocole de transfert hypertexte (HTTP).
Une portion de la première ligne de cette en-tête HTTP représente en fait un artefact du renifleur de paquets TCP/IP utilisé dans le présent exemple et non une partie de la demande HTTP actuelle envoyée. Il en est de même pour tous les segments HTTP de ce chapitre.
Le serveur reçoit les en-têtes envoyés par le navigateur, comme illustré dans la sortie suivante générée par notre programme espion, et traite la demande :
La fonction recv permet de recevoir des données provenant d'un socket. Dans la sortie, le nombre initial 21 représente le socket utilisé par le serveur. "Completed (179)" indique la valeur de renvoi de la fonction, dans le cas présent qu'elle a bien reçu 179 octets. Cette valeur correspond au nombre d'octets envoyés par le navigateur.
Le serveur envoie le document HELLO.HTM au navigateur :
[21:send:(535)]HTTP/1.0 200 OK
Date : Monday, 30-Sep-98 23:33:00 GMT
Server: WebSite/1.1
Allow-ranges: bytes
Accept-ranges: bytes
Connection: Keep-Alive
Content-type: text/html
Last-modified: Monday, 30-Sep-98 23:30:38 GMT
Content-length: 297
<HTML>
<HEAD><TITLE>Hello, World!</TITLE></HEAD>
<BODY>
<FORM ACTION="/cgi-win/hello.exe" METHOD="POST">
What is your name? <INPUT TYPE="text" NAME="name" SIZE=60><BR>
<INPUT TYPE="submit" VALUE="Submit the form">
<INPUT TYPE="reset" VALUE="Clear all fields">
</FORM>
</BODY> </HTML>
Dans ce cas, WebSite envoie un total de 535 octets au navigateur. Ces octets se décomposent en un en-tête de réponse , suivi d'une ligne vierge puis du document HTML lui-même. Les champs d'en-tête indiquent, entre autres choses, le nombre d'octets (l'en-tête Content-length) et le format (l'en-tête Content-type) des données transmises. "200 OK" représente un code d'état indiquant que la demande du navigateur a été exécutée. Tout comme le navigateur, le serveur indique également qu'il utilise une version 1.0 du protocole de transfert hypertexte (HTTP).
Le navigateur lit les en-têtes et les données envoyés par le serveur :
[73:recv: posted]
[73:recv: completed (260)]HTTP/1.0 200 OK
Date : Monday, 30-Sep-98 23:33:00 GMT
Server: WebSite/1.1
Allow-ranges: bytes
Accept-ranges: bytes
Connection: Keep-Alive
Content-type: text/html
Last-modified: Monday, 30-Sep-98 23:30:38 GMT
Content-length: 297
<HTML>
<HEAD><TITLE>H
[73:recv: posted]
[73:recv: completed (275)]ello, World!</TITLE></HEAD>
<BODY>
<FORM ACTION="/cgi-win/hello.exe" METHOD="POST">
What is your name? <INPUT TYPE="text" NAME="name" SIZE=60><BR>
<INPUT TYPE="submit" VALUE="Submit the form">
<INPUT TYPE="reset" VALUE="Clear all fields">
</FORM>
</BODY> </HTML>
Même si deux opérations recv sont nécessaires pour récupérer les enregistrements d'en-tête avec le document, le nombre total d'octets lus durant ces deux opérations est égal au nombre total d'octets envoyés par le serveur.
Le navigateur affiche le formulaire invitant l'utilisateur à saisir son nom et, une fois que l'utilisateur l'a saisi et cliqué sur le bouton Soumettre, il envoie les éléments suivants au serveur :
Le navigateur transmettant des données de formulaire, le type de demande HTTP est "POST", comme l'indique le tout premier enregistrement d'en-tête. De même, les enregistrements Content-length et Content-type indiquent que le navigateur transmet 14 octets de données x-www-form-urlencoded dans le corps de la demande. Ces octets contiennent les informations entrées par l'utilisateur dans le champ de données uniques du formulaire, la zone de texte name.
Le serveur reçoit les enregistrements d'en-tête et les données de formulaire transmises par le navigateur à l'étape précédente. (cette étape étant identique à celle du texte envoyé par le navigateur, il n'est pas nécessaire d'en remontrer un exemple). L'URL (/cgi-win/hello.exe) provoque le lancement de l'application CGI HELLO.EXE par le serveur qui lui transmet les données du formulaire. Il se peut que l'application CGI procède à un traitement déporté, puis génère un document HTML à la volée et le renvoie au serveur.
Le serveur renvoie le document HTML au navigateur ainsi que les enregistrements d'en-tête requis, comme illustré dans la sortie suivante de l'espion WSock32 :
[18:send:(422)]HTTP/1.0 200 OK
Date : Monday, 30-Sep-98 23:33:10 GMT
Server: WebSite/1.1
Allow-ranges: bytes
Accept-ranges: bytes
Connection: Keep-Alive
Content-type: text/html
Content-length: 231
<HTML><HEAD>
<TITLE>Welcome to this Web Page!</TITLE></HEAD>
<BODY><H1>Welcome to Our Web Server!</H1><p><p>
Hello, Jayne Doe! We're glad that you took
the time out of your busy day to visit us!
<HR></PRE></BODY></HTML>
Le serveur indique au navigateur qu'il lui envoie 231 octets d'un document HTML.
Le navigateur reçoit le flux de données envoyé par le serveur et l'utilise pour afficher la page HTML.
Espérons que cet exemple vous aura permis de mieux comprendre les enjeux d'un échange entre navigateur et serveur. Il est important, cependant, d'examiner plus en détail certains points abordés de façon succinte et d'expliquer par la même occasion certaines fonctionnalités supplémentaires qui ne figuraient pas dans cet exemple simple.
Types de demande HTTP
Le type de la demande est transmis par le client au serveur afin d'indiquer au serveur ce qu'il doit faire de l'URL également fournie par le navigateur. Même si la spécification HTTP détaille un certain nombre de types de demande, comme par exemple PUT et DELETE, seuls deux types sont pris en charge par tous les serveurs et communément utilisés : GET et POST. Une demande GET demande au serveur d'"acquérir" une information, généralement un document, et de la renvoyer au client. Si la demande inclut des informations supplémentaires, celles-ci sont ajoutées sous forme d'arguments à l'URL. Une demande POST, en revanche, fournit au serveur des informations à "envoyer" à l'URL ; elle est généralement utilisée pour envoyer les contenus d'un formulaire HTML au serveur, ou bien pour fournir au serveur des informations requises pour un traitement déporté. Les informations quant à elles sont contenues dans le corps de la demande.
La plupart des serveurs ne peuvent pas gérer en interne les données envoyées par les méthodes POST ou GET. En règle générale, les demandes POST de même que les demandes GET envoyant également des données au serveur sont gérées par des programmes accessoires ou des DLL (applications CGI et ISAPI applications et filtres ISAPI). Les demandes POST comme GET peuvent renvoyer des données de tout type et de toute taille.
Même si GET et POST semblent fonctionner de la même manière pour transmettre des données au serveur, il y a une règle nette et rapide : Une demande GET ne doit jamais rien modifier. Ne rédigez pas de script ASP apportant des modifications à une base de données, par exemple, en réponse à une demande GET. Vous trouverez une explication détaillée à cette question à la Section 7.1.3.
Soumission de formulaires
Un utilisateur entre des données dans les champs d'un formulaire. Lorsque le formulaire est soumis, les données contenues dans chaque champ du formulaire sont transférées au serveur, qui les transmet ensuite à la page ASP. Ces données sont envoyées au format name=value, où name correspond au nom affecté au champ par l'attribut NAME= de la balise <INPUT>, et value représente la valeur saisie dans ce champ. Par exemple, si l'utilisateur saisit "Archie" dans un champ l'invitant à saisir son prénom, le navigateur peut envoyer la chaîne first_name=Archie.
Si le formulaire est rédigé pour utiliser METHOD=GET , les données du formulaire sont ajoutées à l'URL sous forme de chaîne d'argument. Si le formulaire contient plusieurs champs ou si des champs contiennent de longues chaînes de texte, la longueur totale de l'URL peut générer des problèmes de maniabilité. En outre, la limite du nombre de caractères soumis dans une demande GET, généralement autour de 2000, est bien inférieure à celle d'une demande POST.
Si le formulaire utilise plutôt METHOD=POST, les paires name=value sont envoyées comme étant le corps de la demande au lieu d'être ajoutées à l'URL. Outre une plus grande facilité de gestion des demandes POST, la plupart des serveurs présentent de meilleures résultats en extrayant les données provenant du corps d'une demande plutôt que d'une URL de l'en-tête de demande.
Utiliser toujours la méthode POST avec des formulaires apportant une quelconque modification ou à l'origine d'action irréversible (comme le font la plupart). Le fonctionnement d'une demande POST est plus sûr et plus efficace ; une demande GET ne doit jamais être utiliser pour modifier un élément. En développant vos scripts ASP, vous pouvez choisir de prendre en charge ou non les données transmises à votre programme à l'aide de la méthode GET.
Demande et réponse HTTP
Les en-têtes constituent les éléments HTTP les moins bien maîtrisés alors que comprendre leur rôle permet de mieux comprendre les propriétés et méthodes des objets ASP Request et Response.
Examinons un courriel Internet quelconque. Il est composé de deux parties, l'en-tête et le corps. L'en-tête comprend plusieurs lignes décrivant le corps du message et peut-être la manière dont le message a été géré lorsqu'il vous a été acheminé. L'en-tête et le corps sont séparés par une ligne vierge. (Pour plus d'informations sur la syntaxe des en-têtes, voir RFC-822.)
Un message HTTP (qu'il s'agisse d'une demande ou d'une réponse) est structuré de la même manière. La première ligne est particulière, mais toutes les autres lignes jusqu'à la première ligne vierge sont des en-têtes semblables à celles d'un courriel. L'en-tête décrit la demande et son contenu, le cas échéant, ou bien la réponse et son contenu.
La demande
A la Section 7.1.1 un certain nombre de demandes du navigateur ont été illustrées. Voici un autre exemple d'une demande HTTP simple :
La première ligne, considérée comme la ligne de demande, décrit le type de demande (ou méthode), dans le cas présent POST, l'URL et enfin, la version du protocole HTTP utilisée par le client. La deuxième ligne décrit les types de documents acceptés par le client. La troisième ligne représente un en-tête "supplémentaire" non requis par le protocole HTTP. Elle fournit le nom et la version du logiciel client. Ensuite, comme indiqué à la Section 7.1.1, deux lignes décrivent les informations contenues dans le corps de la demande.
Tous les éléments jusqu'à la ligne vierge obligatoire incluse font partie de l'en-tête de demande HTTP. Outre ces exemples de lignes, cette section peut comporter d'autres lignes. Par exemple, si le navigateur envoie des informations contenues dans un "cookie", ces informations figureront également dans l'en-tête de la demande.
Le corps de la demande HTTP se situe sous la ligne vierge obligatoire. Dans la plupart des cas, cette section de la demande est vide (par exemple, si le navigateur demande uniquement une page statique et n'envoie pas d'informations). Cependant, si la méthode POST est utilisée, les informations envoyées au serveur web figurent dans cette section de la demande.
La première ligne de la réponse est également particulière et est considérée comme la ligne d'état. Elle contient la version du protocole utilisée par le serveur, plus un code d'état et une phrasede raison. Le serveur utilise le code d'état et la phrase de raison pour signaler au navigateur s'il a pu répondre à sa demande ou non ; dans le cas présent, il a répondu avec succès à la demande de document du navigateur. La deuxième ligne contient la date et l'heure à laquelle le serveur a géré la demande. La troisième ligne est une ligne d'en-tête décrivant le logiciel et la version du serveur. La quatrième ligne indique la date et l'heure de la dernière modification apportée au document demandé. Les deux dernières lignes décrivent le type de données et le nombre d'octets du document demandé. Elles sont suivies d'une ligne vierge, puis du corps du message qui contient les données du document renvoyées par le serveur au navigateur pour les afficher.
Comme pour la demande HTTP, tous les éléments situés au-dessus de la ligne vierge obligatoire font partie de l'en-tête de réponse HTTP. Les éléments situés en-dessous de cette ligne font partie du corps de la réponse.
Le présent chapitre traite de l'objet ASP Request qui permet d'accéder aussi bien à l'en-tête qu'au corps de la demande HTTP. Le chapitre suivant traite de l'objet ASP Response utilisé en manipulant la réponse HTTP du serveur web.
La demande HTTP et l'objet ASP Request
Comme mentionné précédemment, l'objet ASP Request permet d'accéder aussi bien à l'en-tête qu'au corps de la demande HTTP envoyée au serveur web par le navigateur du client. La méthode de récupération des informations de la demande HTTP est à peu de choses près la même pour un script ASP que pour une application CGI. Les exceptions ne proviennent pas du mécanisme de demande mais de la manière dont chaque type d'application est chargée dans le serveur web (filtre CGI opposé au filtre ISAPI), comme décrit dans les deux premiers chapitres de ce manuel.
Tout comme pour les applications CGI, le navigateur du client peut envoyer des informations à un script ASP de deux manières différentes. Tout d'abord, il peut envoyer des informations par le biais d'un formulaire HTML en utilisant la méthode GET :
<HTML>
<HEAD><TITLE>Welcome to the Corp.</TITLE></HEAD>
<BODY>
<FORM ACTION=" http://mycorp.com/secure.asp" METHOD="GET">
First name: <INPUT TYPE="text" NAME="first_name" SIZE=60><BR>
Last name: <INPUT TYPE="text" NAME="last_name" SIZE=60><BR>
<INPUT TYPE="submit" VALUE="Submit the form">
<INPUT TYPE="reset" VALUE="Clear all fields">
</FORM>
</BODY> </HTML>
Lorsque le client soumet une demande GET, les informations relatives à la demande sont ajoutées à la fin de l'URL de la demande sous forme de paires nom/valeur séparées par des esperluettes et précédées d'un point d'interrogation. Chaque nom correspond à un élément du formulaire. Supposons par exemple que l'utilisateur a saisi Horatia et Thompson dans les deux champs du dernier exemple, puis cliqué sur le bouton Soumettre. Du point de vue serveur, voici à quoi ressemble le formulaire soumis :
Si l'utilisateur avait du saisir cette ligne dans la ligne d'adresse ou cliquer sur un lien contenant la ligne précédente comme URL, le serveur web aurait traiter la demande HTTP résultante exactement comme si les informations avaient été envoyées comme une partie d'un formulaire utilisant la demande GET. Depuis votre application ASP, vous pouvez accéder à ces informations par l'intermédiaire de la collection QueryString de l'objet Request. Par exemple :
permet d'initialiser la variable strFirstName sur la valeur envoyée dans le paramètre first_name. De plus amples informations concernant la collection QueryString sont disponibles dans les prochaines sections du présent chapitre.
Tout comme pour les applications CGI, vous pouvez également envoyer des informations à un script ASP en utilisant la méthode POST. Dans ce cas, les informations ne font plus partie de l'en-tête de demande HTTP, mais figurent dans le corps de l'objet de la demande :
<HTML>
<HEAD><TITLE>Welcome to the Corp.</TITLE></HEAD>
<BODY>
<FORM ACTION="http://mycorp.com/secure.asp" METHOD="POST">
First name: <INPUT TYPE="text" NAME="first_name" SIZE=60><BR>
Last name:<INPUT TYPE="text" NAME="last_name" SIZE=60><BR>
<INPUT TYPE="submit" VALUE="Submit the form">
<INPUT TYPE="reset" VALUE="Clear all fields">
</FORM>
</BODY> </HTML>
La soumission de ce formulaire génèrera une demande HTTP semblable à la suivante :
Pour permettre à votre application de manipuler les informations envoyées dans cette demande HTTP, il vous faudra utiliser la collection Form de l'objet Request :
<%
strFirstName = Request.Form("first_name")
%>
Elle permet d'initialiser la variable strFirstName sur la valeur envoyée dans le paramètre first_name. De plus amples informations concernant la collection Form sont disponibles dans les prochaines sections du présent
chapitre.
L'objet ASP Request
Les propriétés, collections, méthodes et événements de l'objet ASP Request figurent dans le cadre suivant.
Résumé de l'objet Request
Propriétés
TotalBytes
Collections
ClientCertificate
Cookies
Form
QueryString
ServerVariables
Méthodes
BinaryRead
Evénements
Aucun
Commentaires/Dépannage
La précédente section concernant ASP et les méthodes GET et POST a permis de souligner que l'utilisation de la collection QueryString permettait de récupérer les informations d'une demande GET et l'utilisation d'une collection Form celles d'une demande POST. Cette méthode fonctionne certes, mais il existe un moyen encore plus simple : vous n'avez pas besoin de spécifier de collection. Par exemple, le code :
strName = Request("name")
renvoie la valeur de la clé "name", indépendamment de la collection dans laquelle elle se trouve, IIS recherchant dans toutes les collections. Si vous spécifiez une valeur de la manière suivante, ASP recherche chaque collection de l'objet Request dans l'ordre suivant :
QueryString
Form
Cookies
ClientCertificate
ServerVariables
La variable en cours d'initialisation recevra la valeur de la première instance de la paire nom/valeur pour laquelle le nom correspond à la chaîne demandée. Vous devez donc bien comprendre que si la même paire nom/valeur figure dans une ou plusieurs collections, vous recevrez la première occurrence trouvée en fonction de la séquence précédente, sauf si vous spécifiez une collection particulière.
Comme pour les autres collections du modèle d'objet ASP, toutes les collections de l'objet Request abordées dans le présent chapitre prennent en charge les propriétés Item et Key, la méthode Count et l'élément For..Each.
TotalBytes
Var= Request.TotalBytes
La propriété TotalBytes est une valeur en lecture seule qui spécifie le nombre total d'octets envoyés au serveur web par le client dans le corps de la demande HTTP. Cette propriété est utile lorsque le serveur se prépare à lire les données du corps de la demande à l'aide de la méthode BinaryRead de l'objet Request.
Paramètres
Var
Reçoit le nombre total d'octets figurant dans le corps de la demande HTTP du client lorsque les données sont envoyées au serveur web. La propriété TotalBytes n'est qu'en lecture seule.
Exemple
Cet exemple suppose que l'utilisateur a répondu au formulaire suivant :
<HTML>
<HEAD><TITLE>File Upload Form</TITLE></HEAD>
<BODY>
<FORM ENCTYPE = "multipart/form-data"
ACTION= "http://mycorp.com/secure.asp" METHOD="POST">
Select a file to upload:
<INPUT TYPE="file" NAME="filename"><BR>
<INPUT TYPE="submit" VALUE="Submit the form">
</FORM>
</BODY> </HTML>
Vous pouvez utiliser la propriété TotalBytes pour déterminer le nombre exact d'octets d'informations envoyés au serveur web dans la demande HTTP :
<%
' The following code retrieves the total number of
' bytes sent in the user's HTTP request. This variable
' is then used to determine how many bytes to retrieve
' using the Request object's BinaryRead method.
Dim lngTotalByteCount
Dim vntRequestData
lngTotalByteCount = Request.TotalBytes
vntRequestData = Request.BinaryRead(lngTotalByteCount)
%>
Remarques
Il est très rare que vous ayez besoin d'accéder aux données figurant dans le corps de la demande HTTP au niveau inférieur fourni par la méthode BinaryRead de l'objet Request, et par conséquent, que vous ayez besoin de récupérer la valeur de la propriété TotalBytes. Les collections Form et QueryString sont utilisées pour accéder à la quasi majorité des données de demande.
Dans l'exemple précédent, la valeur vntRequestData représente le nombre total d'octets envoyés, pas simplement le nombre d'octets du fichier téléchargé ; c'est-à-dire que toutes les informations d'en-tête de la demande HTTP sont également comptabilisées dans ce total. Pour ne récupérer que les contenus du fichier du précédent téléchargement, il vous faudra analyser les informations d'en-tête.
La collection ClientCertificate de l'objet Request permet d'accéder aux champs de certification du certificat numérique du client. Les certificats de client sont envoyés au serveur web lorsque le navigateur d'un client prend en charge le protocole SSL (Secure Sockets Layer, couche des sockets sécurisés) et que ce navigateur est connecté à un serveur web fonctionnant également sous protocole SSL (c'est-à-dire que l'URL commence par https:// au lieu de http://). Par exemple, si vous utilisiez Internet Explorer alors que vous étiez connecté à un site web Internet Information Server tout en exécutant le protocole SSL, toutes les demandes effectuées par votre navigateur contiendront votre certificat de client, si vous en possédez un. Les champs d'un certificat de client sont spécifiés dans la recommandation International Telecommunications Union (ITU) X.509.
La collection ClientCertificate, comme les autres collections ASP, possède les propriétés suivantes :
Item
Renvoie la valeur d'un élément spécifique de la collection. Pour spécifier un élément, vous pouvez utiliser un indice ou un champ clé.
Key
Représente le nom d'un élément spécifique de la collection ClientCertificate. Tout comme chaque valeur d'élément est représentée par la propriété Item, chaque nom d'élément est représenté par sa propriété Key.
Si vous ne connaissez pas le nom d'une clé spécifique, vous pouvez l'obtenir en utilisant sa référence ordinale. Par exemple, supposons que vous vouliez connaître le nom de la clé du troisième élément de la collection et, par conséquent, la valeur de cet élément. Vous pouvez utiliser le code suivant :
Si, en revanche, vous savez que le nom de la clé du troisième élément est "ISSUER", vous pouvez tout simplement utiliser le code suivant pour récupérer la valeur de cet élément :
Comme pour d'autres collections ASP, vous pouvez récupérer la valeur de tout champ de la collection ClientCertificate en utilisant la propriété Item. Item étant la propriété par défaut de la collection, la syntaxe peut être abrégée de manière à ne pas montrer l'utilisation explicite de la propriété Item. Par exemple :
Pour plus d'informations sur les propriétés Item, Key et Count d'une collection, voir les explications de la Section 4.2 duchapitre 4.
Les valeurs Key disponibles sont prédéfinies et sont les suivantes :
Certificate
Une valeur de chaîne contenant la totalité du flux binaire provenant du contenu du certificat. Le contenu est récupéré au format ASN.1 (Abstract Syntax Notation One) standard, la norme internationale utilisée pour représenter les types et les structures de données.
Flags
Un ensemble d'indicateurs fournissant des informations supplémentaires sur le certificat du client. Ces indicateurs sont des valeurs entières qui peuvent être représentées par les constantes ceCertPresent et ceUnrecognizedIssuer si le fichier d'inclusion VBScript cervbs.inc est inclus dans vos scripts (voir
chapitre 11, pour plus d'informations sur les fichiers d'inclusion). Comme le suggère les noms de constante, ceCertPresent indique qu'un certificat de client est présent, et ceUnrecognizedIssuer que le certificat numérique du client a été émis par une autorité de certification inconnue.
Issuer
Une chaîne contenant plusieurs informations sur l'émetteur du certificat numérique du client. Si aucun paramètre Sous-clé (décrit ultérieurement) n'est ajouté, l'utilisation de la clé Emetteur renvoie une liste séparée par des virgules de toutes les valeurs des sous-champs Emetteur (par exemple, C=US, O=VeriSign, GN=Weissinger, etc.).
SerialNumber
Une représentation ASCII des octets hexadécimaux du numéro de série de certification du client. Cette valeur est fournie par l'émetteur. Récupérer la clé SerialNumber permet d'obtenir un nombre tel que 0A-B7-34-23.
Subject
Une liste de chaînes séparée par des virgules fournissant des informations sur le propriétaire du certificat numérique. Si aucun paramètre Sous-clé n'est fourni, la totalité de la liste de sous-champs séparés par des virgules est récupérée, comme précédemment décrit pour la clé Emetteur.
ValidFrom
La date de début de validité du certificat. La valeur de cette clé est fournie sous forme de date et d'heure. Par exemple, une valeur possible de la clé ValidFrom (aux Etats-Unis) serait 1/29/98 12:01:00 A.M.
ValidUntil
La date de fin de validité du certificat. La valeur de cette clé est fournie sous forme de date et d'heure. Par exemple, une valeur possible de la clé ValidUntil (aux Etats-Unis) serait 1/28/99 11:59:59 P.M.
Vous pouvez ajouter une "sous-clé" à certaines valeurs Clés pour récupérer un sous-champ individuel de l'une des listes de clé Emetteur ou Objet. Par exemple, pour connaître la valeur de la sous-clé du pays d'origine à partir de la liste de clé Emetteur, vous récupérez la valeur :
Request.ClientCertificate("IssuerC")
Pour récupérer la valeur de la sous-clé de la localité à partir de la liste de clé Objet, vous récupérez sa valeur en utilisant la syntaxe :
Request.ClientCertificate("SubjectL")
Vous pouvez également récupérer la valeur d'une sous-clé spécifique, y compris celles non répertoriées ici, à partir de la valeur de chaîne de la clé Certificat en utilisant l'identificateur ASN.1 de la sous-clé. Un identificateur ASN.1 correspond à une liste de nombres séparés par un point, d'aspect semblable à une adresse IP, mais non limitée jusqu'à 255 caractères. Par exemple : 3.56.7886.34.
Les sous-clés disponibles sont les suivantes :
C
Le pays d'origine de l'objet ou de l'émetteur.
CN
Le nom commun de la clé Object. Cette sous-clé n'est pas définie pour la clé Emetteur.
GN
Le nom donné de l'objet ou de l'émetteur.
I
Les initiales de l'objet ou de l'émétteur.
L
La localité de l'objet ou de l'émetteur.
O
Le nom de l'organisme ou de la société de l'objet ou de l'émetteur.
OU
Le nom de l'unité organisationnelle spécifique d'un organisme ou d'une société pour un objet ou un émetteur.
S
L'état (ou la province) de l'objet ou de l'émetteur.
T
Le titre de l'objet ou de l'émétteur.
Exemple
<%
' The following code retrieves the country of origin
' for the client's certificate issuer.
strCertIssuerCountry = Request.ClientCertificate("IssuerC")
%>
<!-- #include file="cervbs.inc" -->
<%
' The next example code determines whether the
' issuer is recognized by using the flags key.
If Request.ClientCertificate("Flags") _
and ceUnrecognizedIssuer Then
%>
Your identification is in question because your issuer
is not recognized.
<%
Else
%>
Welcome to our site.
<%
End If
' Finally, the following code iterates through the
' ClientCertificate collection and writes the key-key
' value pairs to the response buffer.
For Each key In Request.ClientCertificate
Response.Write "The " & key & " key contains the value "
Response.Write Request.ClientCertificate(key) & "<BR>"
Next
%>
Remarques
Avant de pouvoir récupérer des informations d'un certificat numérique de client, vous devez vérifier que le navigateur web du client utilise le protocole SSL3.0/PCT1 dans les demandes qu'il envoie à votre site. Pour ce faire, la solution la plus simple est d'essayer de récupérer un élément de la collection ClientCertificate.
Vous devez également vérifier avoir bien défini que votre serveur web IIS demande des certificats de client.
Si le client n'envoie aucun certificat numérique, toutes les clés que vous tenterez de récupérer dans la collection ClientCertificate seront vides.
La Recommandation ITU X.509 n'est justement qu'une recommandation. Elle n'a pas le statut d'une norme officielle. De nombreux certificats de société peuvent donc fonctionner légèrement différemment ou bien peuvent ne pas contenir tous les champs que vous tentez de récupérer. Pour garantir la bonne identification de vos clients, il est recommandé de tester la collection ClientCertificate avant de pouvoir s'y fier.
Avant de traiter la collection Cookies, revenons brièvement sur le concept des cookies HTTP. Cette présentation sera rapide. Pour de plus amples informations, veuillez soit consulter Netscape Preliminary Specification à l'adresse suivante, http://www.netscape.com/newsref/std/cookie_spec.html, soit consulter Cookie Central, un centre d'échange de toutes les informations relatives aux cookies. Il est tout particulièrement conseillé de se rendre à cette adresse, http://www.cookiecentral.com/unofficial_cookie_faq.htm.
Le problème avec un protocole sans état comme HTTP est qu'il oblige le serveur comme le client à effectuer de nombreuses tâches répétitives. Par exemple, avec un véritable protocole sans état, le serveur web devrait vous demander de vous identifier chaque fois que vous naviguez dans une page du site, même si vous avez atteint cette nouvelle page depuis une autre page du même site. De même, votre interaction se limitera à ce que vous pourrez saisir et enregistrer sur une seule et même page d'informations, car sans moyen de stocker les données d'une page, il n'y a aucune chance pour qu'une seconde page puisse les afficher.
Netscape Communications Corp. avait prévu ce problème dès le début et conçu une méthode permettant au serveur web de stocker des informations sur la machine du client web. Ces informations sont à leur tour envoyées au serveur chaque fois que le client demande une page extraite de la même zone que celle d'où proviennent les informations. Ces petits fragments d'informations représentent la racine du mécanisme d'état des clients persistants de Netscape ou plus connus sous le nom de "cookies". (à noter que, conformément à la spécification préliminaire de Netscape, cet objet d'état a été appelé cookie "sans aucune raison particulière").
Les cookies permettent aux serveurs web de stocker des informations sur la machine client de manière sécurisée et de les récupérer ensuite très facilement, offrant ainsi des possibilités quasi-illimitées pour l'e-commerce. Les sites web sont désormais en mesure de conserver un suivi de votre identité, de votre dernière visite ou du type de livres que vous aimez, par exemple.
Le fonctionnement des cookies est très simple. Ils sont envoyés au client par le biais d'un en-tête de réponse HTTP Set-Cookie au format suivant (tous les en-têtes Set-Cookie doivent tenir sur une seule ligne) :
La paire nom/valeur du cookie spécifique que le serveur web souhaite enregistrer sur la machine client. La valeur peut contenir tout type de caractère, à l'exception des espaces blancs, des virgules et des points virgules. Cette partie du cookie est obligatoire.
expires
Contient une date après laquelle le navigateur peut disposer du cookie. Si aucun attribut expires n'est indiqué, la valeur par défaut est fixée à la fin de la session HTTP active. Le format de la date d'expiration est le suivant :
Wdy, DD-Mon-YYYY HH:MM:SS GMT
Seuls les temps moyens de Greenwich sont admis.
domain
Chaque fois que l'utilisateur navigue dans une URL spécifique, les attributs de domaine de tous les cookies figurant sur la machine utilisateur sont comparés au domaine de l'URL. Si l'attribut de domaine d'un cookie présent sur la machine utilisateur correspond à la "queue" du domaine de l'URL (les deux derniers segments du nom de domaine complet), ce cookie est alors envoyé comme en-tête Request (plus de détails disponibles dans les sections à venir) à cette URL. Le nom d'un domaine doit contenir au moins deux points pour pouvoir définir l'attribut de domaine d'un cookie envoyé au client. Par exemple, www.microsoft.com peut envoyer des cookies à votre machine (et il le fait), mais mydomain.com ne peut le faire. La valeur réelle de l'attribut domain du cookie Microsoft serait Microsoft.com.
Ce cookie serait alors envoyé à toutes les URL terminant par Microsoft.com, y compris www.microsoft.com, home.microsoft.com. De même, seules les pages de ce domaine peuvent définir des cookies avec cet attribut de domaine. Par exemple, www.microsoft.com peut envoyer des cookies avec comme domaine Microsoft.com, mais www.ora.com ne peut le faire.
Si aucun attribut de domaine n'est inclus dans le cookie envoyé au navigateur du client, la valeur par défaut correspond au nom de domaine de l'émetteur du cookie. Ce paramètre est facultatif.
path
Le sous-ensemble des URL du domaine défini par l'attribut domain du cookie. Sa valeur détermine si le cookie est renvoyé ou non au serveur. Si aucun attribut de chemin n'est envoyé, la valeur par défaut correspond au chemin d'accès du document affiché par le navigateur. Par exemple, les cookies de http://www.oreilly.com/newtitles/upcoming.ASP ne possédant pas d'attribut de chemin d'accès défini auront comme valeur par défaut /newtitles/. Le navigateur n'enverra les cookies de cette page qu'aux pages de ce chemin d'accès. Le chemin d'accès le plus répandu pour un domaine est "/". Cet attribut est facultatif.
Le problème du chemin d'accès peut parfois engendrer des confusions. La machine du navigateur enregistre-t-elle un cookie par page sur un chemin ou bien enregistre-t-elle un seul cookie sans cesse réutilisé ? Pour répondre à cette question, le navigateur enregistre en fait un cookie pour chaque valeur de cookie individuel. Il n'existe pas de cookie unique contenant les valeurs de cookie de la page active. Chaque valeur de cookie a sa propre entrée.
secure
Si présent pour un cookie, ordonne au navigateur d'envoyer ce cookie uniquement aux pages contenues dans le chemin d'accès spécifié dans la propriété path si le serveur et le navigateur communiquent via un canal sécurisé (HTTPS, par exemple).
Si l'utilisateur navigue dans une URL pour laquelle un cookie figure sur la machine locale, le navigateur envoie un en-tête Request au format suivant :
Cookie:Name1=Value1;Name2=Value2;...NameX=ValueX;
où :
NameX
correspond au nom d'un cookie de cette URL.
ValueX
correspond à la valeur du cookie correspondant ayant pour nom NameX. Cette valeur doit représenter une chaîne sans espace, point-virgule ou virgule.
Prenons un exemple pour mieux comprendre. Supposons qu'un client navigue dans une URL et que son navigateur reçoive les en-têtes de réponse HTTP suivants :
A compter de ce moment et jusqu'au 10 novembre 2000 à 11:59 P.M., le premier cookie sera envoyé au serveur web chaque fois que le client naviguera dans une page d'un domaine dont les deux derniers segments sont yourbooks.com. L'en-tête de demande HTTP aura l'aspect suivant :
Cookie: userid=a.keyton.weissinger
A compter de ce moment et jusqu'au 1 janvier 2010 à 11:59 P.M., le deuxième cookie sera envoyé à toutes les pages du domaine yourbooks.com dont le chemin d'accès correspond à /sales/something. Par exemple, l'en-tête de demande de cookie suivant :
Cookie: usersel=aspbooks
serait envoyé à http://www.yourbooks.com/sales/default.ASP ou à http://www.yourbooks.com/sales/final/asp, ou encore à http://www.yourbooks.com/sales/checkout/default.ASP.
Enfin, si les deux jeux de critères (des deux cookies userid et usersel) sont remplis, l'en-tête de cookie suivant sera envoyé au navigateur de l'utilisateur :
Vous devez connaître de nombreux autres détails relatifs aux cookies si vous envisagez de les utilisez souvent. Voir les précédentes références pour plus d'informations. Cette brève présentation étant maintenant terminé, nous allons passer à la collection Cookies de l'objet Request.
La collection Cookies de l'objet Request permet à votre application ASP de récupérer les valeurs des cookies et les éléments de dictionnaire des cookies provenant du corps de la demande HTTP du client.
La collection Cookies, comme les autres collections ASP, possède les propriétés suivantes :
Item
Représente la valeur d'un cookie spécifique de la collection. Pour spécifier un cookie, vous pouvez utiliser un indice ou un champ clé.
Key
Représente le nom d'un élément spécifique de la collection Cookies. Tout comme chaque valeur d'élément est représentée par la propriété Item, chaque nom d'élément est représenté par sa propriété Key.
Si vous ne connaissez pas le nom d'une clé spécifique, vous pouvez l'obtenir en utilisant sa référence ordinale. Par exemple, supposons que vous vouliez connaître le nom de la clé du troisième élément de la collection et, par conséquent, la valeur de cet élément. Vous pouvez utiliser le code suivant :
Si, en revanche, vous savez que le nom de la clé du troisième élément est "STATE", vous pouvez tout simplement utiliser le code suivant pour récupérer la valeur de cet élément :
strKeyValue = Request.Cookies.Item("STATE")
Count
Représente le nombre d'éléments de la collection.
Comme pour d'autres collections ASP, vous pouvez récupérer la valeur de tout champ de la collection Cookies en utilisant la propriété Item. Dans les exemples et explications fournis ici, la syntaxe a été abrégée de manière à ne pas montrer l'utilisation explicite de la propriété Item. Par exemple :
Pour plus d'informations sur les propriétés Item, Key et Count d'une collection, voir les explications de la Section 4.2 duchapitre 4.
Outre stocker des valeurs simples, un cookie de la collection Cookies peut représenter un dictionnaire de cookies. Un dictionnaire est un élément semblable à une table associative dans le sens où chaque élément de la table peut être identifié par son nom.
Cependant, même si un cookie peut contenir un dictionnaire de cookies, il ne peut pas contenir plusieurs types de donénes complexes, comme par exemple des objets.
Pour déterminer une valeur spécifique dans un dictionnaire de cookies, vous devez utiliser un paramètre SubKey. Par exemple, supposons qu'un cookie spécifique représente les cinq couleurs choisies par un utilisateur sur une page web. Le cookie est appelé Colors et les sous-clés ont les noms suivants : color1, color2, . . . color5. Pour déterminer la valeur figurant dans color3, vous devrez utiliser un code semblable à celui-ci :
strColor3 = Request.Cookies("Colors")("color3")
Pour déterminer si un cookie spécifique possède des sous-clés ou non, vous devez utiliser la propriété HasKeys de ce cookie spécifique, comme suit :
blnHasKeys = Request.Cookies("Colors").HasKeys
If blnHasKeys Then
strColor3 = Request.Cookies("Colors")("color3")
End If
Exemple
<%
' The following code iterates through the Cookies collection.
' If a given cookie represents a cookie dictionary, then
' a second, internal for...each construct iterates through
' it retrieving the value of each subkey in the dictionary.
Dim strCookie
Dim strSubKey
Dim str3rdCookieValue
Dim strCompanyCookieValue
For Each strCookie In Request.Cookies
If Request.Cookies(strCookie).HasKeys Then
' The cookie is a dictionary. Iterate through it.
%>
The cookie dictionary <%=strCookie%> has the
following values:
<%
For Each strSubKey In Request.Cookies(strCookie)
%>
SubKey: <%= strSubKey %><BR>
Value:
<%=Request.Cookies(strCookie)(strSubKey)%><BR>
<%
Next
Else
' The cookie represents a single value.
%>
The cookie <%=strCookie%> has the following value:
<%=Request.Cookies(strCookie)%> <BR>
<%
End If
Next
' The following code retrieves the value of the third cookie
' in the Cookies collection.
str3rdCookieValue = Request.Cookies(3)
' The following code retrieves the value of the "company"
' cookie in the Cookies collection.
strCompanyCookieValue = Request.Cookies("Company")
%>
Remarques
Lorsque vous accédez à un cookie représentant un dictionnaire de cookies, si vous ne spécifiez pas de sous-clé, vous récupérerez une valeur de chaîne semblable à celle-ci :
Une partie de la structure du cookie sur la machine du clientre est un chemin d'accès représentant la page web qui a envoyé le cookie au client. Un point important concernant la récupération des valeurs de cookie entre en ligne de compte lorsqu'il existe deux cookies possédant le même nom, mais des chemins d'accès différents. Dans un cas pareil, si vous tentez de récupérer le cookie, vous ne récupérerez que le cookie provenant du répertoire le plus profond. Par exemple, si la page web http://www.MyCompany.com/ContribApp/Contrib1.ASP possède un cookie nommé UserPref et qu'une seconde page web avec un chemin d'accès plus profond, par exemple, http://www.MyCompany.com/ContribApp/Addresses/AddrContrib1.ASP, possède également un cookie nommé UserPref, si vous tentez de récupérer le cookie UserPref, vous ne récupérerez que le second cookie UserPref.
Si vous tentez de récupérer la valeur d'une sous-clé pour un nom de cookie ne représentant pas un dictionnaire de cookies, le résultat sera nul. Pour cette raison, vous devez utiliser la propriété HasKeys avant de tenter de récupérer la valeur d'une sous-clé.
Comme vous le savez, le mécanisme d'état de client persistant HTTP (plus connu sous le nom de cookies) évolue sans cesse. Toutes les versions de cookie restent valides pendant six mois. La version actuelle, de même que cette rédaction, est disponible à l'adresse ftp://ftp.isi.edu/internet-drafts/draft-ietf-http-state-man-mec-08.txt.
Vous découvrirez dans ce document (ou sa version mise à jour) que la toute dernière version de la spécification des cookies va bien au-delà de celle initialement proposée par Netscape. De toute évidence, la collection Cookies actuelle de l'objet Request ne prend en charge que certains éléments de cette spécification. Lorsque cette dernière version sera devenue une norme, de nombreux aspects des cookies pourront être récupérés par l'intermédiaire de la collection Request Cookies.
Form
<FORM ACTION = "RecordPrefs.asp" METHOD = POST>
Name: <INPUT TYPE = TEXT NAME = "Name"><BR>
Color Pref: <SELECT NAME = "optColor">
<OPTION VALUE = "red" SELECTED>Red
<OPTION VALUE = "blue" >Blue
<OPTION VALUE = "green" >Green
</SELECT><BR>
Have a Modem? <INPUT TYPE = CHECKBOX NAME = "Modem"><BR>
<INPUT TYPE=submit VALUE=submit>
</FORM>
La collection Form permet de récupérer les informations saisies dans un formulaire HTML sur le client et envoyées au serveur à l'aide de la méthode POST. Ces informations se trouvent dans le corps de la demande HTTP envoyée par le client.
La collection Form, comme les autres collections ASP, possède les propriétés suivantes :
Item
Représente la valeur d'un élément spécifique de la collection. Pour spécifier un élément, vous pouvez utiliser un indice ou un champ clé. Dans le cas de la collection Form, l'indice représente le numéro de l'élément dans le formulaire HTML. Prenons par exemple le formulaire HTML suivant :
<FORM ACTION = "RecordPrefs.asp" METHOD = POST>
Name: <INPUT TYPE = TEXT NAME = "Name"><BR>
Color Pref: <SELECT NAME = "optColor">
<OPTION VALUE = "red" SELECTED>Red
<OPTION VALUE = "blue" >Blue
<OPTION VALUE = "green" >Green
</SELECT><BR>
Have a Modem? <INPUT TYPE = CHECKBOX NAME = "Modem"><BR>
<INPUT TYPE=submit VALUE=submit>
</FORM>
Dans RecordPrefs.ASP, le premier élément (élément 1) est "Name." Le troisième élément est "Modem." Notez que la numérotation commence par un (1).
Key
Représente le nom d'un élément spécifique de la collection Form. Tout comme chaque valeur d'élément est représentée par la propriété Item, chaque nom d'élément est représenté par sa propriété Key.
Si vous ne connaissez pas le nom d'une clé spécifique, vous pouvez l'obtenir en utilisant sa référence ordinale. Par exemple, supposons que vous vouliez connaître le nom de la clé du troisième élément de la collection et, par conséquent, la valeur de cet élément. Vous pouvez utiliser le code suivant :
Si, en revanche, vous savez que le nom de la clé du troisième élément est "STATE", vous pouvez tout simplement utiliser le code suivant pour récupérer la valeur de cet élément :
strKeyValue = Request.Form.Item("STATE")
Vous ne pouvez pas toujours compter sur l'ordre dans lequel les éléments Form sont stockés. Par exemple, le formulaire que avez soumis peut contenir huit éléments. Vous n'avez aucun moyen de savoir si le premier élément de votre formulaire correspond au premier élément de la collection Form. Vous devez donc toujours utiliser une chaîne de clé pour identifier l'élément spécifique de la collection Form que vous souhaitez.
Count
Renvoie le nombre d'éléments de la collection.
Comme pour d'autres collections ASP, vous pouvez récupérer la valeur de tout champ de la collection Form en utilisant la propriété Item. Dans les exemples et explications suivants, la syntaxe a été abrégée de manière à ne pas montrer l'utilisation explicite de la propriété Item. Par exemple :
strFirstName = Request.Form("txtFirstName")
représente uniquement une forme abrégée de :
strFirstName = Request.Form.Item("txtFirstName")
Pour plus d'informations sur les propriétés Item, Key et Count d'une collection, voir les explications de la Section 4.2 duchapitre 4.
Exemple
Les exemples de la collection Form de l'objet Request utilisent tous le formulaire HTML suivant :
<HTML>
<HEAD>
<TITLE>User Information</TITLE>
</HEAD>
<BODY>
<CENTER>
<H1>User Information</H1>
Please enter your user information using the form below:
<FORM NAME = "frmInfo" ACTION="UserInfo.ASP"
METHOD = "POST">
First Name: <INPUT TYPE="text" NAME = "txtFirstName"><BR>
Last Name: <INPUT TYPE="text" NAME = "txtLastName"><BR>
Zipcode: <INPUT TYPE="text" NAME = "txtZipCode"><BR>
Occupation: <INPUT TYPE="text" NAME = "txtOccupation"><BR>
Please select your connection speed:
<SELECT NAME = "optConnSpeed">
<OPTION VALUE = "28.8" SELECTED>28.8 Modem
<OPTION VALUE = "ISDN" >ISDN
<OPTION VALUE = "T1" >T1
<OPTION VALUE = "T3" >T3
</SELECT><BR>
Below, select all the peripherals you have:
<INPUT TYPE = "checkbox" NAME = "chkPeriph"
VALUE = "Joystick">Joystick<BR>
<INPUT TYPE = "checkbox" NAME = "chkPeriph"
VALUE= "GraphicsAccel">3D Graphics Card<BR>
<INPUT TYPE = "checkbox" NAME = "chkPeriph"
VALUE = "Printer">Printer<BR>
<BR>
Check here if it's ok to send your information:
<INPUT TYPE = "checkbox" NAME = "chkSellInfo"><BR>
<INPUT TYPE = "Submit" VALUE = "Submit User Info">
</FORM>
</BODY>
</HTML>
Une fois que le client a cliqué sur le bouton Soumettre du formulaire, les informations du formulaire sont envoyées au serveur web dans le corps du corps de a demande HTTP à l'aide de la méthode Post du protocole HTTP.
Le code suivant peut être utilisé dans UserInfo.ASP pour déterminer les valeurs des éléments spécifiques du formulaire frmInfo de l'exemple précédent. Avant d'écrire ce code, vous devez au préalable connaître les champs exacts du formulaire à traiter.
<%
' The following code example demonstrates the use of
' the Form collection of the Request object to retrieve
' the values entered by the client into an HTML form.
Dim strFirstName
Dim strLastName
Dim strZipCode
Dim strOccupation
Dim blnSendInfo
Dim strConnSpeed
Dim intPeriphCount
Dim aryPeripherals( )
Dim chkItem
intPeriphCount = 0
' Retrieve the information from the form's text boxes.
strFirstName = Request.Form("txtFirstName")
strLastName = Request.Form("txtLastName")
strZipCode = Request.Form("txtZipCode")
strOccupation = Request.Form("txtOccupation")
' Retrieve the information from the Sell Information
' checkbox.
blnSendInfo = Request.Form("chkSellInfo")
' Determine the connection speed from the Connection
' Speed option buttons.
strConnSpeed = Request.Form("optConnSpeed")
' Populate an array with the peripherals the user has.
For Each SubKey in Request.Form("chkPeriph")
ReDim Preserve aryPeripherals(intPeriphCount + 1)
intPeriphCount = intPeriphCount + 1
aryPeripherals(intPeriphCount) = _
Request.Form("chkPeriph")(intPeriphCount)
Next
%>
Remarques
Si vous faites référence à un élément ne possédant pas d'indice et que cet élément contient plusieurs valeurs, votre code renverra une chaîne séparée par des virgules. Supposons par exemple qu'au lieu d'avoir utiliser une sous-clé avec l'élément chkPeriph de la collection Form précédemment dans le chapitre, la ligne de code suivante ait été incluse :
response.write Request.Form("chkPeriph")
Si ces trois options (Joystick, GraphicsAccel et Printer) ont été sélectionnées, cette ligne de code génèrera la chaîne suivante :
Joystick, GraphicsAccel, Printer
Votre application peut également récupérer des données non analysées dans la demande HTTP du client. Pour récupérer des données non analysées dans le corps de la demande HTTP, vous devez utiliser Request.Form sans aucun paramètre défini. Utiliser des données de demande HTTP non analysées, précisément des données binaires, de cette manière peut poser problème. Cependant, de nombreuses commandes ActiveX et applets Java permettent de récupérer des données binaires de façon plus efficace.
Pour soumettre les informations d'un formulaire HTML à une application ASP, vous devez affecter l'attribut ACTION de la balise <FORM> au nom du fichier qui traitera les données du formulaire HTML. Cette application ASP peut figurer dans le même répertoire virtuel ou peut être spécifiée en fonction de son propre répertoire virtuel. Vous pouvez effectuer cette action à partir d'une page HTML ou d'un autre fichier ASP. Cependant, l'une des applications les plus performantes de ce procédé est la construction d'une ASP s'appelant elle-même. Cela n'est pas forcément plus rapide, mais son développement est plus efficace.
Dans l'exemple suivant, une ASP simple crée un formulaire HTML dont les données saisies sont traitées par la même ASP :
<%
' UserInfo2.ASP
' The following code determines whether the HTML form (see
' the bottom portion of the script) has been filled out. If
' it has, then some processing takes place and one HTML output
' is sent back to the client. If not, the HTML form is sent to
' the client.
If Not IsEmpty(Request.Form("txtFirstName")) And _
Not IsEmpty(Request.Form("txtLastName")) Then
' The form has been filled out and the reply is
' a brief thank you.
%>
<HTML>
<HEAD><TITLE>Thank You</TITLE>
</HEAD>
<BODY>
Thank you, <%= Request.Form("txtFirstName")%>
<%= Request.Form("txtLastName")%> for your information.
Have a nice day.
</BODY>
</HTML>
<%
Else
%>
<HTML>
<HEAD><TITLE>Thank You</TITLE>
</HEAD>
<BODY>
<FORM NAME = "frmInfo" ACTION="UserInfo2.ASP"
METHOD = "POST">
First Name: <INPUT TYPE="text" NAME="txtFirstName"><BR>
Last Name: <INPUT TYPE="text" NAME="txtLastName"><BR>
<INPUT TYPE = "Submit" VALUE = "Submit User Info">
</FORM>
</BODY>
</HTML>
<%
End If
%>
Ce script détermine tout d'abord si les éléments du formulaire ont bien été remlis par le client. Le cas échéant, ce script envoie alors un bref message de remerciement "Thank You" au client et le script se termine. Si les informations n'ont pas été saisies, le formulaire est présentée à l'utilisateur. Même si le formulaire utilisé ici est rudimentaire, cette technique est très performante peut vous permettre de modulariser votre code, une tâche souvent difficile dans le développement des applications ASP.
Si votre formulaire HTML contient des commandes ActiveX en plus (ou en remplacement) des éléments de formulaire HTML standard, vous pouvez faire référence à leurs valeurs de la même manière. Prenons par exemple le formulaire HTML (simple) suivant qui contient une zone de texte Microsoft Forms 2.0 unique :
<FORM NAME = "frmInfo" ACTION="UserInfo.ASP"
METHOD = "POST">
First Name:
<OBJECT NAME = "txtFirstName" WIDTH=211 HEIGHT=20
CLASSID="CLSID:8BD21D10-EC42-11CE-9E0D-00AA006002F3">
<PARAM NAME="VariousPropertyBits" VALUE="746604571">
<PARAM NAME="BackColor" VALUE="16777215">
<PARAM NAME="MaxLength" VALUE="255">
<PARAM NAME="Size" VALUE="5574;529">
<PARAM NAME="Value" VALUE=">
<PARAM NAME="BorderColor" VALUE="0">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
<PARAM NAME="FontWeight" VALUE="0">
</OBJECT>
<INPUT TYPE = "Submit" VALUE = "Submit User Info">
</FORM>
Vous pouvez faire référence à la valeur saisie dans la zone de texte de UserInfo.ASP en utilisant la ligne de code suivante :
strFirstName = Request.Form("txtFirstName")
Si votre formulaire HTML contient des commandes ActiveX dont les valeurs ont été validées à l'aide d'un script client, vérifiez qu'aucun des éléments (le bouton de soumission par exemple) ne possède le nom Soumettre. Cela peut vous paraître superflu, mais si vous négligez cet aspect, vous ne pourrez pas soumettre votre formulaire ! Essayez et vous verrez.
Les données de la collection Form représentent uniquement les données du corps de la demande HTTP. Vous pouvez également utiliser la méthode Get HTTP pour envoyer au serveur des données provenant du client. Si vous utilisez la méthode Get, les informations sont extraites du client puis envoyées dans l'en-tête de la demande HTTP. Pour récupérer ces données, vous devez utiliser la collection QueryString de l'objet Request.
La collection QueryString permet de récupérer les informations envoyées par le client en utilisant la méthode Get HTTP à l'aide d'un formulaire HTML et de données ajoutées à l'URL lorsque la page est demandée. La collection QueryString est moins performante que la collection Form, puisque le volume de données pouvant être envoyées dans l'en-tête d'une demande HTTP est limité. Par expérience, cette limite se situe autour de 2000 caractères. Si plus de 2000 caractères sont envoyés dans la collection QueryString, ils ne seront pas traités même si le script continue de s'exécuter.
La collection QueryString, comme les autres collections ASP, possède les propriétés suivantes :
Item
Renvoie la valeur d'un élément spécifique de la collection. Pour spécifier un élément, vous pouvez utiliser un indice ou un champ clé. Dans le cas de la collection QueryString, l'indice représente le numéro de l'élément tel qu'il apparaît dans l'URL ou le numéro de l'élément dans le formulaire HTML (sous réserve qu'une méthode GET soit utilisée pour envoyer les données). Cependant, si vous utilisez méthode POST pour soumettre les données du formulaire, ces éléments HTML ne figurent pas dans la collection QueryString, mais plutôt dans la collection Form de l'objet Request.
Key
Renvoie le nom d'un élément spécifique de la collection QueryString. Tout comme chaque valeur d'élément est représentée par la propriété Item, chaque nom d'élément est représenté par sa propriété Key.
Si vous ne connaissez pas le nom d'une clé spécifique, vous pouvez l'obtenir en utilisant sa référence ordinale. Par exemple, supposons que vous vouliez connaître le nom de la clé du troisième élément de la collection et, par conséquent, la valeur de cet élément. Vous pouvez utiliser le code suivant :
Si, en revanche, vous savez que le nom de la clé du troisième élément est "STATE", vous pouvez tout simplement utiliser le code suivant pour récupérer la valeur de cet élément :
strKeyValue = Request.QueryString.Item("STATE")
Count
Le nombre d'éléments de la collection.
Comme pour d'autres collections ASP, vous pouvez récupérer la valeur de tout champ de la collection QueryString en utilisant la propriété Item. Dans les exemples et explications suivants, la syntaxe a été abrégée de manière à ne pas montrer l'utilisation explicite de la propriété Item. Par exemple :
Pour plus d'informations sur les propriétés Item, Key et Count d'une collection, voir les explications de la Section 4.2 duchapitre 4.
Exemple
<%
' This code iterates through the QueryString collection
' and fills an array with the values retrieved.
Dim item
Dim aryQueryValues( )
Dim intItemCount
intItemCount = 0
For Each item In Request.QueryString
ReDim Preserve aryQueryValues(intItemCount + 1)
aryQueryValues(intItemCount) = _
Request.QueryString(item)
intItemCount = intItemCount + 1
Next
%>
Remarques
Tout comme les éléments de la collection Form, les éléments de la collection QueryString peuvent représenter plusieurs valeurs. Imaginons par exemple que votre fichier ASP reçoive une soumission du formulaire HTML suivant :
<FORM NAME = "frmInfo" ACTION="UserInfo2.ASP"
METHOD = "GET">
Below, select all the peripherals you have:
<INPUT TYPE = "checkbox" NAME = "chkPeriph" VALUE =
"Joystick">Joystick<BR>
<INPUT TYPE = "checkbox" NAME = "chkPeriph" VALUE =
"GraphicsAccel">3D Graphics Card<BR>
</FORM>
L'utilisation est supposé avoir coché les deux cases. Les informations induites seront interprétées dans l'ASP de la même manière que si l'ASP avait été appelée à l'aide de l'URL suivante :
Si vous ne spécifiez pas de sous-clé, comme dans :
strOptions = Request.QueryString("chkPeriph")
alors strOptions aura la valeur suivante :
Joystick, GraphicsAccel
Comme la collection Form, la collection QueryString contient des informations envoyées par le client au serveur web. Ces informations peuvent se présenter sous la forme de paires paramètre/valeur ajoutées à la fin de l'URL demandée dans l'en-tête de la demande HTTP, ajoutées à l'URL dans le champ d'adresse du navigateur ou extraites d'un formulaire HTML dont l'action est définie dans la méthode Get HTTP.
L'utilisation de la collection QueryString présente certaines restrictions, la plus importante étant sa longueur limitée. Même si cette longueur varie en fonction du volume de mémoire disponible sur le serveur et le client, ce dernier ne pourra pas envoyer plus de ~1800 caractères au serveur en utilisant la collection QueryString. Cette "limite" de ~1800 caractères est comprise entre la fin du nom de script appelé et la fin de la liste de paramètres ajoutée à l'URL demandée, y compris les noms et pas uniquement les valeurs, des paramètres envoyés.
Tout comme les éléments de la collection Form, les éléments de la collection QueryString peuvent contenir plusieurs valeurs. Pour déterminer le nombre de valeurs disponibles pour un élément spécifique de la collection, utilisez la propriété Count de l'élément en question. La valeur de la propriété Count correspond au nombre de valeurs contenues dans l'élément et elle est égale à zéro (0) si l'élément ne figure pas dans la collection.
Vous pouvez récupérer toutes les valeurs d'un élément à plusieurs valeurs donné en ignorant le paramètre de référence de l'élément spécifique. Les valeurs sont renvoyées sous forme de chaîne séparée par des virgules contenant uniquement les valeurs de l'élément concerné.
Comme avec la collection Form, vous pouvez récupérer des données non analysées dans la collection QueryString. Pour récupérer les données brutes non analysées de la collection QueryString, vous devez utiliser la syntaxe Request.QueryString sans aucun paramètre d'élément.
Les données de la collection QueryString sont également accessibles depuis la collection ServerVariables de l'objet Request, en utilisant le paramètre HTTP_QUERYSTRING . Ce point est traité plus en détal dans la section concernant la colection ServerVariables.
Enfin, vous devez coder plusieurs caractères spéciaux lorsque vous les utilisez dans la collection QueryString :
&
L'application ASP utilise l'esperluette pour délimiter des paires paramètre/valeur distinctes qui ont été ajoutées à la collection QueryString.
?
Le point d'exclamation délimite le début de la collection QueryString ajoutée après l'extension du nom de fichier dans le nom de fichier demandé dans l'URL par le client.
%
Le signe pourcentage es utilisé pour coder d'autres caractères spéciaux.
+
Le signe plus est considéré comme un espace dans la collection QueryString.
Ces caractères peuvent être codés automatiquement au moyen des méthodes URLEncode et HTMLEncode de l'objet Server côté serveur ou d'un script personnalisé côté client.
La collection ServerVariables contient plusieurs variables d'environnement prédéfinies dans le cadre de la demande HTTP spécifique du client du serveur web.
La collection ServerVariables, comme les autres collections ASP, possède les propriétés suivantes :
Item
La valeur d'un élément spécifique de la collection. Pour spécifier un élément, vous pouvez utiliser un indice ou un champ clé.
Key
Renvoie le nom d'un élément spécifique de la collection ServerVariables. Tout comme chaque valeur d'élément est représentée par la propriété Item, chaque nom d'élément est représenté par sa propriété Key.
Si vous ne connaissez pas le nom d'une clé spécifique, vous pouvez l'obtenir en utilisant sa référence ordinale. Par exemple, supposons que vous vouliez connaître le nom de la clé du troisième élément de la collection et, par conséquent, la valeur de cet élément. Vous pouvez utiliser le code suivant :
Si, en revanche, vous savez le nom de la clé du troisième élément est "QUERY_STRING", vous pouvez tout simplement utiliser le code suivant pour récupérer la valeur de cet élément :
Comme pour d'autres collections ASP, vous pouvez récupérer la valeur de tout champ de la collection ServerVariables en utilisant la propriété Item. Dans les exemples et explications suivants (et dans quasiment tous les exemples issus d'autres sources), la syntaxe a été abrégée de manière à ne pas montrer l'utilisation explicite de la propriété Item. Par exemple :
Pour plus d'informations sur les propriétés Item, Key et Count d'une collection, voir les explications de la Section 4.2 duchapitre 4.
Les valeurs possibles de la propriété Key figurent dans la liste suivante. Même si elles apparaissent généralement en majuscules, la propriété Key est en fait insensible à la casse. Tout comme les éléments des autres collections ASP, les valeurs d'élément de la collection ServerVariables peuvent également être récupérées au moyen d'un indice. Cependant, la liste suivante est affichée par ordre alphabétique, et non dans l'ordre d'apparition des éléments dans la collection ServerVariables.
ALL_HTTP
Une longue chaîne contenant tous les en-têtes HTTP envoyés par le navigateur du client. Tous les éléments suivants peuvent être analysés à partir de cet élément.
ALL_RAW
Une longue chaîne contenant tous les en-têtes HTTP dans l'état original dans lequel le navigateur du client les a envoyés. La principale différence entre les valeurs ALL_RAW et ALL_HTTP réside dans le fait que les valeurs de l'élément ALL_HTTP possèdent toutes le préfixe HTTP_ et le nom d'en-tête est toujours en majuscules. Tous les éléments suivants peuvent être analysés à partir de cet élément.
APPL_MD_PATH
La métabase IIS du programme contient tous les paramètres du serveur. Son fonctionnement est similaire à celui de la base de registres, excepté le fait que la métabase ne contient que les informations concernant les éléments ajoutés (comme des jeux d'outils intégrables) à la Console de gestion Microsoft. Cela peut inclure Internet Information Server (IIS), Index Server et SQL Server 7.0, entre autres. Les informations contenues dans la métabase correspondent presque exclusivement à des informations d'installation et de configuration.
L'élément APPL_MD_PATH de la collection ServerVariables représente le chemin spécifique de la métabase pour la DLL ISAPI. Il s'agit du chemin de la métabase qu'appelle la DLL ISAPI, et non son emplacement physique sur le serveur. Par exemple, sur une machine sous Windows 95 (exécutant un Serveur Web Personnel), la valeur de cet élément est la suivante :
/LM/W3SVC/1/ROOT
APPL_PHYSICAL_PATH
Le chemin d'accès physique de l'élément APPL_MD_PATH. La valeur est récupérée de la conversion de l'élément APPL_MD_PATH par IIS. Par exemple, sur le système, cela se traduit par C:\Inetpub\wwwroot\.
AUTH_PASSWORD
Si la sécurité IIS est définie sur Authentification de base, AUTH_PASSWORD représente le mot de passe saisi dans le champ d'authentification lorsque le client s'est connecté au serveur web. Si aucun mot de passe n'est fourni, cette valeur représente une chaîne vide.
AUTH_TYPE
La méthode d'authentification définie sur le serveur web. Cette méthode d'authentification permet de valider tous les utilisateurs demandant des scripts sur le serveur protégé par la sécurité Windows NT.
AUTH_USER
Le nom d'utilisateur brut saisi lors de l'authentification du client par le serveur web.
CERT_COOKIE
Un ID unique pour le certificat numérique du client. La valeur de cet élément peut être utilisée comme signature pour tout le certificat. Cet élément n'a de valeur que pour les clients utilisant le protocole HTTPS. La collection ClientCertificate contient toutes les informations concernant les certificats numériques du client. La collection ClientCertificate est plus facile à utiliser que les informations d'en-tête HTTP. Si le client n'envoie pas de certificat numérique, ces éléments CERT_ figurent toujours dans la collection ServerVariables, mais ils sont vides (c'est-à-dire qu'ils n'ont pas de valeur).
CERT_FLAGS
CERT_FLAGS représente une valeur binaire. L'octet n°0 est défini sur 1 si le certificat du client est présent. L'octet n°1 est défini sur 1 si l'autorité de certification du certificat du client est invalide (c'est-à-dire que l'émetteur est introuvable dans la liste des émetteurs de certificat vérifié figurant sur le serveur web). Ces valeurs correspondent aux constantes ceCertPresent et ceUnrecognizedIssuer de l'élément Flags de la collection ClientCertificate.
CERT_ISSUER
L'émetteur du certificat du client, le cas échéant. La valeur de cet élément est une chaîne séparée par des virgules et contenant les sous-champs de chaque sous-éléments possibles précédemment décrits dans la section des éléments Emetteur de la collection ClientCertificate.
CERT_KEYSIZE
Le nombre de bits utilisés pour créer la clé de connexion SSL (Secure Sockets Layer) (par exemple, 64 ou 128).
CERT_SECRETKEYSIZE
Le nombre de bits contenus dans la clé privée du certificat du serveur secret (par exemple, 1024).
CERT_SERIALNUMBER
La valeur du numéro de série du certificat du client.
CERT_SERVER_ISSUER
L'émetteur du certificat du serveur.
CERT_SERVER_SUBJECT
Le champ Objet du certificat du serveur. Tout comme le champ Objet du certificat du client, la valeur de cet élément représente une chaîne séparée par des virgules et contenant les sous-champs décrits dans la section des éléments Objet de la collection ClientCertificate.
CERT_SUBJECT
Le champ Objet du certificat du client. La valeur de cet élément représente une chaîne séparée par des virgules et contenant les sous-champs décrits dans la section des éléments Objet de la collection ClientCertificate.
CONTENT_LENGTH
La longueur totale du corps du corps de la demande HTTP envoyée par le client. Vous pouvez utiliser cette valeur pour déterminer la longueur du contenu HTTP brut de la demande HTTP du client. Cette valeur n'inclut pas la longueur des données présentées via l'en-tête de demande (c'est-à-dire les informations envoyées à l'aide d'une méthode GET), mais uniquement les informations figurant dans le corps de la demande.
CONTENT_TYPE
Il s'agit du type MIME du contenu envoyé par le client. Si vous l'utilisez avec des requêtes HTTP contenant des informations annexes (comme par exemple, les actions HTTP GET, POST et PUT), cet élément peut permettre de déterminer le type des données du contenu de la demande HTTP du client. La valeur la plus courante de cet élément est application/x-www-form-urlencoded. Si vous voulez inclure un élément de fichier dans votre formulaire HTML, vous devez définir le paramètre ENCTYPE (et par conséquent, l'en-tête CONTENT_TYPE de votre demande) sur multipart/form-data.
GATEWAY_INTERFACE
La révision de l' Interface de passerelle commune utilisée par le serveur web. La valeur de cette chaîne est au format CGI/revision#. Par exemple, si vous étiez connecté à un serveur web IIS 4.0, la valeur de cet élément serait CGI/1.1.
HTTP_ [HeaderName]
La valeur envoyée dans l'en-tête HTTP appelée headername. Pour récupérer la valeur d'un en-tête HTTP quelconque non mentionné dans cette liste (y compris les en-têtes personnalisés), vous devez préfixer le nom d'en-tête avec la valeur HTTP_. Si vous spécifiez un en-tête HTTP_CUSTOM_SELECTION, IIS recherchera un en-tête HTTP apppelé Custom-Header par le client dans sa demande HTTP. En d'autres termes, lorsque vous recherchez dans la collection ServerVariables un en-tête HTTP dont le nom contient des tirets, vous devez plutôt utiliser des traits de soulignement. Si vous tentez de récupérer un en-tête non existant, une chaîne vide est renvoyée, et non pas une erreur. Par exemple, chacun des en-têtes suivants :
HTTP_ACCEPT
HTTP_AUTHORIZATION (identique à l'élément AUTH_TYPE)
HTTP_ACCEPT-LANGUAGE
HTTP_CONNECTION
HTTP_HOST
HTTP_REFERER
HTTP_USER-AGENT
nécessite un code semblable à celui-ci pour recevoir sa valeur :
La valeur de cet élément est la chaîne "ON" si la demande HTTP du client a été envoyée en utilisant SSL. Elle correspond à "OFF" autrement.
HTTPS_KEYSIZE
Identique à l'élément CERT_KEYSIZE décrit précédemment.
HTTPS_SECRETKEYSIZE
Identique à l'élément CERT_SECRETKEYSIZE décrit précédemment.
HTTPS_SERVER_ISSUER
Identique à l'élément CERT_SERVER_ISSUER décrit précédemment.
HTTPS_SERVER_SUBJECT
Identique à l'élément CERT_SERVER_SUBJECT décrit précédemment.
INSTANCE_ID
L'ID de l'instance IIS actuelle spécifiée au format texte. Si l'évaluation de cet élément renvoie 1, la valeur est alors une chaîne. L'élément INSTANCE_ID représente le numéro de l'instance du serveur web auquel appartient cette demande. Cet élément n'est utile que si plusieurs instances du serveur web sont exécutées sur le serveur. Sinon, cette valeur correspond toujours à 1, représentant la seule (et unique) instance du serveur web de la machine.
INSTANCE_META_PATH
Le chemin d'accès à la métabase de l'instance IIS sur lequel la demande HTTP du client est envoyée. Comme expliqué précédemment dans la section sur l'élément APPL_MD_PATH de la collection ServerVariables, la métabase contient des informations spécifiques à l'installation et la configuration de votre serveur web. Pour une machine exéctant un serveur web personnel, la valeur de cet élément est /LM/W3SVC/1.
LOCAL_ADDR
L'adresse TCP/IP du serveur web qui accepte la demande HTTP du client. Cet élément de la collection ServerVariables a une importance toute particulière lorsque le serveur web réside dans une ferme de serveurs de plusieurs machines possédant toutes des adresses IP distinctes, toutes les réponses demandent le même nom de domaine. Si vous accédez au serveur en tant que localhost, sa valeur est 127.0.0.1.
LOGON_USER
Le compte utilisateur Windows NT avec lequel l'utilisateur s'est connecté au système si la sécurité est définie sur basique ou sur défi-réponse Windows NT. Pour garantir une sécurité anonyme, il renvoie une chaîne vide.
PATH_INFO
Le chemin d'accès virtuel de la page web à partir de laquelle le client a effectué sa demande HTTP. Si l'évaluation de ces informations renvoie à un répertoire virtuel, ce répertoire est mappé à un répertoire physique avant d'être envoyé au filtre CGI.
PATH_TRANSLATED
Le mappage virtuel-physique de la valeur de l'élément PATH_INFO de la collection ServerVariables.
QUERY_STRING
Les valeurs envoyées par le client situées après le point d'interrogation (?) à la fin de l'URL de la demande HTTP. Cet élément contient également les informations envoyées au serveur web au moyen de la méthode HTTP GET. Toutes les informations contenues dans cet élément sont également disponibles via la collection QueryString (plus facile à utiliser puisqu'elle ne requiert pas d'analyse).
REMOTE_ADDR
L'adresse TCP/IP du client.
REMOTE_HOST
L'adresse IP à partir de laquelle le serveur web reçoit la demande HTTP du client. Si la demande HTTP ne contient pas cette information, la valeur de l'élément REMOTE_ADDR sera définie et elle correspondra à une valeur vide.
REQUEST_METHOD
La méthode avec laquelle le client a effectué la demande HTTP (GET, POST, HEAD, etc.).
SCRIPT_NAME
Le chemin d'accès virtuel complet jusqu'au script actuel. Ce chemin n'inclut pas la portion de base de l'URL, représentée par l'élément d'URL de la collection ServerVariables. Il permet (principalement en interne) de procéder à un auto-référentiel des URL. Il est identique à la valeur de l'élément PATH_INFO.
SERVER_NAME
L'adresse TCP/IP du serveur web, son DNS ou nom d'hôte tel qu'il apparaît dans une URL auto-référencée.
SERVER_PORT
Le port du serveur auquel la demande HTTP du client est envoyée. Il correspond généralement à 80 ou 8080 pour la plupart des serveurs web.
SERVER_PORT_SECURE
Si la demande HTTP est gérée par le serveur web sur un port sécurisé, l'évaluation de cette valeur renvoie 1. Si le port n'est pas sécurisé, cette valer correspond à 0.
SERVER_PROTOCOL
Le nom et la version du protocole utilisé par le serveur web pour gérer la demande du client. Par exemple, si le client utilise Microsoft Internet Explorer 4.01 et que le serveur web est IIS 4.0, cette valeur correspond à la chaîne "HTTP/1.1."
SERVER_SOFTWARE
Le nom et la version du logiciel du serveur web gérant la demande HTTP du client. Par exemple, toujours si vous utilisez Microsoft IIS 4.0, un exemple de valeur de cet élément de la collection ServerVariables est Microsoft-IIS/4.0.
URL
L'URL de base demandée par le client dans sa demande HTTP.
Exemple
<%
' The following code determines the value of the
' LOGON_USER item of the ServerVariables collection. This
' code can be used to determine the identity of the
' client.
Dim strUserName
strUserName = Request.ServerVariables("LOGON_USER")
%>
Remarques
Tout comme le montre la liste précédente de cette section, la collection ServerVariables contient de nombreuses informations utiles concernant la demande HTTP du client. Les éléments les plus importants permettent de déterminer l'identité et l'adresse de l'utilisateur. Ils permettent de personnaliser vos performances en matière de sécurité.
De même, de nombreuses données des autres collections de l'objet Request peuvent être obtenues par l'intermédiaire de la collection ServerVariables (généralement plus difficilement, cependant).
BinaryRead
MySafeArray=Request.BinaryRead(ByteCount)
La méthode BinaryRead lit un certain nombre d'octets directement dans le corps de la demande HTTP envoyée par le client comme une partie d'une méthode HTTP Post. Les données lues dans une demande HTTP à l'aide de la méthode BinaryRead sont renvoyées dans une SafeArray. Une SafeArray est une variante de table spéciale contenant en plus de ses éléments, le nombre de dimensions de la table ainsi que les limites supérieurs de la table.
En vérité, une SafeArray ne correspond en aucun cas à une table. Il s'agit d'un type spécial de structure utilisée en interne pour conserver les informations contenues dans sa portion de table. Les valeurs des dimensions et des limites supérieures ne sont disponibles que dans C/C++ comme éléments de la structure. Vous ne pouvez pas manipuler ces valeurs (ni même les récupérer) au moyen d'un script.
Paramètres
MySafeArray
Le nom d'une SafeArray utiliser pour stocker les informations renvoyées par une méthode BinaryRead.
ByteCount
Le nombre d'octets lus au moyen de la méthode BinaryRead. Généralement, la valeur de cette variable est évaluée au nombre d'octets renvoyés par la propriété TotalBytes de l'objet Request décrite précédemment.
Exemple
<%
' The following code determines the total number of bytes
' sent in the client's HTTP request. It then reads the
' bytes, checks for errors, and if there are none,
' reports to the client that the read was successful.
Dim lngTotalByteCount
Dim vntRequestData
On Error Resume Next
lngTotalByteCount = Request.TotalBytes
vntRequestData = Request.BinaryRead(lngTotalByteCount)
If Err = 0 Then
' For details about the Response object, see Chapter 8.
' For now, suffice it to say the following code sends
' information to the client.
Response.Clear
Response.Write lngTotalByteCount & _
" bytes successfully read.<BR>"
Response.End
End If
%>
Remarques
Si l'élément client de votre application web peut contrôler exactement les éléments envoyés dans le corps de la demande HTTP, cette méthode se révèlera très utile puisqu'elle permettra au client de télécharger des informations au niveau octets (ou de télécharger des fichiers). Cependant, contrôler les informations envoyées dans une demande Post au niveau octets s'avère difficile. Plusieurs commandes de transfert de fichiers tiers sont cependant disponibles ; elles permettent d'ajouter des fonctionnalités de transfert de fichiers à votre application de manière plus efficace et plus facile.
Si auparavant vous avez récupéré des informations provenant de la collection Form de l'objet Request, les appels ultérieurs de la méthode BinaryRead génèreront une erreur. De même, si auparavant vous avez appelé la méthode BinaryRead de l'objet Request et que vous tentez par la suite de récupérer des informations de la collection Form, votre script génèrera une erreur.