Uniform Resource Identifier (uri), son objectif et ses composants

1.4. Identifiant de ressource uniforme (URI)

Pour bien comprendre comment les documents HTML interagissent, naviguent entre les pages et d'où l'ordinateur de l'utilisateur reçoit des données lorsqu'il travaille avec le réseau, vous devez considérer comment et à quoi on accède à l'aide du réseau mondial.

De nombreux types de ressources hébergées sur Internet, qu'il s'agisse de documents HTML, d'images ou de fichiers d'archives, sont le plus souvent des fichiers sur le disque dur d'un ordinateur (serveur) connecté à un réseau. Chaque ressource est associée à une valeur qui peut déterminer de manière unique son emplacement - l'identifiant de ressource universel ou URI (Universal Resource Identifier). Les URI sont largement utilisés à la fois lorsqu'un utilisateur accède à une ressource par lui-même (lorsque, par exemple, l'utilisateur saisit lui-même l'URI dans la barre d'adresse d'un navigateur) et lorsqu'il navigue entre des pages Web. Les URI sont également utilisés dans un document HTML pour indiquer au navigateur où rechercher les ressources (telles que les images) utilisées dans le document lui-même.

Noter

La notation URL est également souvent utilisée dans la littérature. Il convient de noter qu'un URI est un concept plus général qui inclut une URL : toute URL est un Uniform Resource Identifier et suit les mêmes règles qu'un URI.

L'URI de l'identificateur de ressource se compose de trois parties : le nom du mécanisme d'accès à la ressource, le nom de domaine de l'ordinateur et le chemin du fichier de ressources. Pour clarifier cela, prenons un exemple :

Ici, vous pouvez voir que HTTP (Hyper Text Transfer Protocol) est utilisé pour accéder à la ressource, qui dans ce cas est un document HTML. La ressource est stockée sur un ordinateur avec le nom de domaine somesite.com dans le fichier ex_1.html situé dans le dossier /info/examples.

Les URI peuvent également faire référence à des parties de documents HTML, par exemple :

En utilisant cet URI, vous pouvez accéder à la partie d'un document HTML nommée description (la manière de créer des noms pour des fragments de documents HTML sera traitée au chapitre 5).

Les URI vous permettent également de faire référence à des ressources au sein du même ordinateur. Ceci spécifie le chemin relatif de la ressource. Par exemple, pour faire référence au fichier /info/files/file1.jpg depuis un document HTML situé dans le dossier /info/examples, il suffit de spécifier l'URI /files/file1.jpg. Dans les documents HTML, ces liens indiquent les chemins d'accès aux images et autres objets utilisés dans les documents, mais pas directement stockés dans ceux-ci.

En général, les URI sont considérés comme insensibles à la casse. Cependant, pour être complètement sûr que l'URI est interprété correctement, faites toujours attention à la casse des caractères dans l'URI des hyperliens, des images, etc. Ceci est utile pour éliminer de telles situations lorsque, par exemple, lorsque le site fonctionne sur un Ordinateur Windows, tous les hyperliens fonctionnent, mais lorsque le site sur un serveur UNIX refuse de fonctionner (sous UNIX, les noms de fichiers sont sensibles à la casse).

Travailler avec les URI

Chaque jour, nous utilisons Identifiants de ressources uniformes (URI) lorsque vous cherchez quelque chose sur le WWW. Les URI sont nécessaires pour identifier et demander un nouveau type de ressource. À l'aide d'un URI, vous pouvez accéder non seulement à des pages Web, mais également à un serveur FTP, à un service Web et à des fichiers locaux.

Le terme est souvent utilisé à la place d'URI Localisateur de ressources uniforme (URL). URI est un terme générique utilisé pour désigner des ressources. Une URL est un URI associé à des schémas d'URI populaires tels que http, ftp et mailto. Dans la documentation technique, le terme URL n'est plus utilisé.

Un autre terme que vous connaissez peut-être déjà - Nom de ressource uniforme (URN). Un URN est un URI normalisé utilisé pour identifier une ressource quel que soit son emplacement sur le réseau.

Analysons les parties d'un URI qui font référence à une page du site Web Global Knowledge :

http://www.globalknowledge.net:80/training/generic.asp?pageid=1078&country=DACH

    La première partie de l'URI est appelée schéma (schéma). Un schéma définit un espace de noms URI et peut restreindre la syntaxe d'une expression suivant le schéma. De nombreux schémas sont nommés d'après les protocoles respectifs (comme http, ftp) qu'ils utilisent, mais ce n'est pas obligatoire. Dans notre exemple, l'identifiant du schéma est http. Délimiteur de circuit(// dans cet exemple) sépare le schéma du reste de l'URL.

    Le délimiteur de schéma est suivi du nom du serveur ou de l'adresse IP en notation décimale avec des points, comme www.globalknowledge.net.

    Derrière le nom du serveur ou l'adresse IP se trouve un numéro de port qui identifie la connexion à une application spécifique sur le serveur. Si aucun numéro de port n'est spécifié, le numéro de port par défaut pour ce protocole est utilisé (par exemple, le port 80 pour HTTP).

    Façon spécifie la page (et le répertoire) de la ressource demandée. Il ne représente pas nécessairement un fichier physique sur le serveur, mais peut être créé dynamiquement. Dans ce cas, le chemin est /training/generic.asp.

    Du chemin du symbole ? séparé la dernière partie de cet URI, appelée mettre en doute. Dans notre exemple, la requête est définie par la chaîne pageid=1078&country=DACH. Une chaîne de requête peut être constituée de plusieurs composants, chacun spécifiant une variable et une valeur, associées au symbole &. Plusieurs composants de requête peuvent être combinés avec le symbole &. Ainsi, dans notre exemple, le premier composant est pageid=1078 avec la variable pageid définie sur 1078, et le second composant est country=DACH.

    Les sections d'une ressource peuvent être identifiées par des fragments. fragments sont utilisés pour créer des liens vers des sections d'une page HTML. Dans le développement de pages Web, les extraits sont également appelés signets. Le caractère # sépare l'identifiant du fragment du chemin. Dans l'URL http;//www.microsoft.com/net/basics/glossary.asp#NETFramework, le fragment est la chaîne #NETFramework.

Si le caractère # est ajouté à la chaîne de requête, il ne s'agit plus d'un fragment. Une URL peut contenir une chaîne de requête ou un fragment, mais pas les deux.

Plusieurs caractères sont réservés dans les URI - ils ne peuvent pas être inclus dans les noms d'hôte ou les chemins car ce sont des caractères de délimitation spéciaux. Les caractères suivants sont réservés dans l'URI :

; / ? : @ & = + $ ,

Classe Uri de l'espace de noms System encapsule l'Uniform Resource Identifier. Il contient des propriétés et des méthodes pour analyser, comparer et combiner des URI.

Vous pouvez créer un objet Uri en transmettant une chaîne URI au constructeur :

Uri URI de base = new Uri("http://site");

S'il existe déjà un objet Uri de base, vous pouvez créer un nouvel URI en combinant l'URI de base avec un URI relatif :

Uri URI de base = new Uri("http://site"); Uri newURI = new Uri(baseURI, "my/csharp/web/level2/2_2.php");

Si l'URI de base contient déjà un chemin, il est ignoré. Le nouvel URI est basé uniquement sur le schéma, le port et le nom du serveur.

La classe Uri possède plusieurs champs statiques en lecture seule qui vous permettent d'obtenir certains des schémas couramment utilisés :

Uri.UriSchemeFileUri.UriSchemeFile

Le schéma de fichiers est utilisé pour accéder aux fichiers localement ou sur des ressources réseau partagées, qui peuvent être nommées selon la convention de dénomination universelle ( Convention de dénomination universelle, UNC).

Uri.UriSchemeFtpUri.UriSchemeFtp

Le protocole FTP avec le schéma ftp permet de recevoir des fichiers d'un serveur ftp et, à l'inverse, de déposer des fichiers sur un serveur ftp.

Uri.UriSchemeGopher

Le protocole gopher était le précurseur de HTTP. Il a fourni des capacités de navigation hiérarchique informations textuelles sur le contenu, dans lequel FTP excellait. Mais il a été rapidement remplacé par le protocole HTTP.

Uri.UriSchemeHttp, Uri.UriSchemeHttps

Ces deux schémas sont bien connus : http et https. Le schéma https est utilisé pour les échanges sécurisés.

Uri.UriSchemeMailtoUri.UriSchemeMailto

Le schéma mailto est utilisé pour envoyer des messages électroniques.

Uri.UriSchemeNews, Uri.UriSchemeNntp

Les schémas news et nntp sont utilisés dans les groupes de discussion qui utilisent le protocole NNTP.

La classe Uri a des méthodes statiques pour vérifier le schéma et le nom d'hôte corrects : Uri.CheckSchemeName() renvoie true si le nom du schéma est correct et la méthode UriCheckHostName() vérifie non seulement le nom d'hôte, mais renvoie également une valeur d'énumération UriHostNameType indiquant le type d'hôte.

La classe Uri possède de nombreuses propriétés en lecture seule qui vous permettent d'accéder à toutes les parties d'un URI. Dans le tableau suivant, nous utilisons l'URI ci-dessus comme exemple pour illustrer l'utilisation des propriétés :

AbsoluteUri Cette propriété affiche l'URI complet. Si le numéro de port spécifié pour le protocole est égal au numéro de port par défaut, le constructeur Uri le supprime automatiquement. Pour notre exemple, la valeur de la propriété AbsoluteUri ressemble à ceci : http://www.globalknowledge.net/training/generic.asp?pageid=1078&country=DACH. Si un nom de fichier est passé au constructeur de la classe Uri, la propriété AbsoluteUri précède automatiquement le nom de fichier avec le schéma file://.
Schème Le schéma est la première partie de l'URI et, dans ce cas, cette propriété renvoie la valeur http.
Héberger La propriété Host affiche le nom d'hôte de l'URI : www.globalknowledge.net
Autorité Si le numéro de port est égal au numéro par défaut utilisé par le protocole, la propriété Authority affiche la même chaîne que la propriété Host. Si un numéro de port différent est utilisé, la propriété Authority affiche également le numéro de port.
type de nom d'hôte Le type de nom d'hôte dépend du nom utilisé. Dans ce cas, la même valeur de l'énumération UriHostNameType décrite ci-dessus est obtenue.
Port En utilisant la propriété Port, le numéro de port est obtenu - 80.
Cheminabsolu Un chemin absolu commence après le numéro de port dans l'URI et se termine avant la chaîne de requête. Dans ce cas, il s'agit de /training/generic.asp.
cheminlocal Le chemin local donne la valeur /training/generic.asp. Comme vous pouvez le voir, pour une requête HTTP, il n'y a pas de différence entre AbsolutePath et LocalPath. La différence apparaît si l'URI fait référence à une ressource réseau partagée. Pour un URI de la forme file:\\server\share\directory\file.txt, la propriété LocalPath renvoie uniquement les noms de répertoire et de fichier, tandis que la propriété AbsolutePath inclut les noms de serveur et de partage.
Mettre en doute La propriété Query affiche la chaîne suivant le chemin : ?pageid=1078&country=DACH.
CheminEtRequête La propriété PathAndQuery donne la combinaison du chemin et de la chaîne de requête : /training/generic.asp?pageid=1078&country=DACH.
Fragment Si le chemin est suivi d'un fragment, il est renvoyé dans la propriété Fragment. Le chemin ne peut être suivi que d'une chaîne de requête ou d'un fragment. Le fragment est identifié par le symbole #
segments La propriété Segments renvoie un tableau de chaînes formé à partir du chemin. Dans ce cas, nous avons trois segments : /, training/ et generic.asp.
Informations utilisateur Le nom d'utilisateur défini dans l'URI peut être lu à partir de la propriété UserInfo. La transmission de noms d'utilisateur est courante dans le protocole FTP, et si un utilisateur non anonyme est spécifié, tel que ftp:// [courriel protégé], la propriété UserInfo renverra myuser.

En plus de celles répertoriées, il existe plusieurs autres propriétés qui renvoient des valeurs booléennes si l'URI représente un fichier, un chemin UNC, une adresse de bouclage ou si le protocole utilise le numéro de port par défaut. Il s'agit respectivement des propriétés IsFile, IsUnc, IsLoopback et IsDefaultPort.

Pour accéder à toutes les ressources du réseau, vous devez savoir où elles se trouvent et comment elles sont accessibles. Le World Wide Web utilise un schéma d'adressage et d'identification normalisé, prenant en compte l'expérience d'adressage et d'identification du courrier électronique, Gopher, WAIS, telnet, ftp, etc. - URL, Localisateur de ressources uniformes.

URI(Uniform Resource Identifier, Uniform Resource Identifier) ​​​​(RFC 2396, août 1998) Chaîne de caractères compacte permettant d'identifier une ressource abstraite ou physique. Une ressource est tout objet appartenant à un espace. Inclut et remplace les URL précédemment définies (RFC 1738/RFC 1808) et les URN (RFC 2141, RFC 2611).

L'URI est destiné à identifier de manière unique toute ressource.

Certains sous-ensembles d'URI :

URNE(Uniform Resource Name) - Un schéma d'URI "urn :" privé avec un sous-ensemble "espace de noms" qui doit être unique et inchangé même si la ressource n'existe plus ou n'est pas disponible.

On suppose que, par exemple, le navigateur sait où chercher cette ressource.

Syntaxe:

urn:namespace: data1.data2,more-data où namespace spécifie comment les données après le deuxième ":" sont utilisées.

Exemple d'URN :

urne :ISBN : 0-395-36341-6

ISBN - classificateur thématique pour les éditeurs

0-395-36341-6 - numéro spécifique du sujet du livre ou du magazine



À la réception d'un URN, le programme client accède à l'ISBN (le répertoire "classificateur de sujets pour les éditeurs" sur Internet). Et il reçoit un décodage du numéro de sujet « 0-395-36341-6 » (par exemple : « chimie quantique »).

URN est largement utilisé dans les réseaux P2P (comme edonkey).

Un exemple d'URN pointant vers une image disque Adobe Photoshop v8.0 sur le réseau edonkey :

urn:ed2k://|fichier|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/

ed2k - pointe vers un réseau

Adobe Photoshop v8.0.iso - nom de fichier

940769280 - taille en octets

- identifiant de fichier (calculé à l'aide d'une fonction de hachage)

URL du localisateur de ressources uniforme :

URL(Uniform Resource Locator, RFC 1738) - un localisateur de ressources unifié (pointeur), une manière normalisée d'enregistrer une adresse de ressource dans le WWW et Internet. L'URL a une structure flexible et extensible pour l'emplacement le plus naturel des ressources sur le réseau, qui identifie la ressource par la manière dont elle est accessible (par exemple, son "emplacement sur le réseau"), au lieu de l'identifier par le nom ou autres attributs de cette ressource.

Exemples d'URL :

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

Un ensemble limité de caractères ASCII est utilisé pour représenter une adresse.

La forme générale de l'adresse peut être représentée comme suit :

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

schéma d'accès aux ressources: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais, etc.

Mot de passe- nom d'utilisateur et mot de passe utilisés pour accéder à la ressource

héberger le nom de domaine de l'hôte ou son adresse IP.

Port- port hôte pour se connecter

chemin complet vers la ressource - spécifiant des informations sur l'emplacement de la ressource (dépend du protocole).

Exemples d'URL :

http://example.com #demande de page de démarrage par défaut

http://www.example.com/site/map.html #demander la page donnée dans le répertoire donné

http://example.com:81/script.php #connectez-vous à un port non standard

http://example.org/script.php?key=value #request avec passage de paramètre au script

ftp://utilisateur : [courriel protégé]#se connecter au serveur ftp avec autorisation

http://192.168.0.1/example/www #connexion à l'adresse réseau

file:///srv/www/htdocs/index.html #opening fichier local

gopher://example.com/1 #se connecter au serveur gopher

URL - Uniform Resource Locators décrit explicitement comment accéder à l'objet.

L'avènement des URL est devenu une innovation importante sur Internet. Cependant, depuis sa création jusqu'à nos jours, la norme URL a un sérieux inconvénient - elle ne peut utiliser qu'un ensemble limité de caractères, encore plus petit qu'en ASCII : des lettres, des chiffres et seulement quelques signes de ponctuation- .

Si nous voulons utiliser des caractères cyrilliques, ou des hiéroglyphes, ou, disons, des caractères français spécifiques dans l'URL, alors les caractères dont nous avons besoin doivent être recodés d'une manière spéciale.

Dans Wikipédia en russe, on voit tous les jours des exemples d'encodage d'URL, car la langue russe utilise des caractères cyrilliques. Par exemple, une ligne comme :

http://en.wikipedia.org/wiki/Microcrédit

encodé dans l'URL comme :

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 %B8%D1%82

Une telle conversion se déroule en deux temps : d'abord, chaque caractère cyrillique est encodé en Unicode (UTF-8) en une séquence de deux octets, puis chaque octet de cette séquence est écrit en représentation hexadécimale :

M → D0 et 9C → %D0%9C

et → D0 et B8 → %D0%B8

à → D0 et BA → %D0%BA

p → D1 et 80 → %D1%80, etc.

Chacun de ces codes d'octets hexadécimaux, selon la spécification de l'URL, est précédé d'un signe de pourcentage (%) - d'où même le terme anglais "percent-encoding" est né, indiquant la façon dont les caractères sont codés dans les URL et les URI.

Étant donné que les lettres de tous les alphabets sont soumises à une telle transformation, à l'exception de l'alphabet latin de base, une URL contenant des mots dans la grande majorité des langues (sauf l'anglais, l'italien, le latin) peut devenir illisible pour une personne.

Tout cela est en contradiction avec le principe d'internationalisme proclamé par toutes les principales organisations de l'Internet, dont le W3C et l'ISOC. Ce problème est destiné à être résolu par la norme IRI (International Resource Identifier) ​​- des identifiants internationaux de ressources dans lesquels les caractères Unicode pourraient être utilisés sans problème, et qui ne porteraient donc pas atteinte aux droits des autres langues.

Autres schémas d'URL

Schéma HTTP.

Le schéma précise son identifiant, l'adresse de la machine, le port TCP, le chemin dans le répertoire du serveur, les variables et leurs valeurs, le label.

Syntaxe:

http://[ [:@][:][?]]

http - nom du schéma

utilisateur - nom d'utilisateur

hôte - nom d'hôte

port - numéro de port

mettre en doute(<имя-поля>=<значение>{&<имя-поля>=<значение>) - chaîne de requête

Défini dans RFC 2068. Par défaut, port=80.

Exemples:
http://ipm.kstu.ru/internet/index.php

Il s'agit du type d'URI le plus couramment utilisé dans Documents Internet. Le nom du schéma (http) est suivi d'un chemin composé de l'adresse de domaine de la machine et de l'adresse complète du document HTML dans l'arborescence du serveur HTTP.

Une adresse IP peut également être utilisée comme adresse machine :

http://195.208.44.20/internet/index.php

Si le serveur de protocole HTTP s'exécute sur autre chose que 80 Port TCP, cela se reflète dans l'adresse :

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
Le caractère "#" sépare le nom du document du nom de l'étiquette.

Les variables et leurs valeurs sont passées comme suit :
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

Les valeurs "var1" et "var2" sont des noms de variables, et "value1" et "value2" sont leurs valeurs.

Schéma FTP

Ce schéma vous permet d'adresser des archives de fichiers FTP.

Syntaxe:

ftp://[ [:@][:]

ftp - nom du schéma

utilisateur - nom d'utilisateur

mot de passe - mot de passe utilisateur

hôte - nom d'hôte

port - numéro de port

url-path - le chemin d'accès au fichier et le fichier lui-même

Défini dans la RFC 1738. Par défaut, port=21, utilisateur=anonyme, mot de passe=adresse e-mail, si un nom est spécifié mais pas de mot de passe, il est demandé dans la boîte de dialogue.

ressemble à:

//...//[;type= ], où :

Exemples : ftp://ipm.kstu.ru/students/name/

Pour spécifier un nom d'utilisateur et un mot de passe, vous devez écrire comme ceci :
ftp://nom : [courriel protégé]://ipm.kstu.ru/students/name/

Dans ce cas, ces paramètres sont séparés de l'adresse machine par le symbole "@", et les uns des autres par deux-points.

Schéma Mailto

Ce schéma est pour l'envoi de courrier.

Syntaxe:

e-mail :[ {,,...}][?]

mailto - nom du schéma

e-mail-1 ( @) - première adresse e-mail

utilisateur - nom d'utilisateur

hôte - nom d'hôte

e-mail-2 - deuxième adresse e-mail

mettre en doute(<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - chaîne de requête

mailto : [courriel protégé]

Dans ce schéma, les champs et leurs valeurs sont passés :

mailto : [courriel protégé]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

L'adresse du destinataire peut également être écrite comme la valeur du champ à :

mailto : [courriel protégé]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

Qu'est-ce que HTTP ?

Le premier document (mais pas une norme) est RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996)

La dernière version est RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee juin 1999)

Le protocole de transfert hypertexte est un protocole de transfert hypertexte, un protocole de haut niveau (c'est-à-dire au niveau de l'application). Utilisé par le service WWW pour transférer des pages Web.

HTTP (HyperText Transfer Protocol, RFC 2616, version actuelle HTTP/1.1) est un protocole de transfert hypertexte. Ce protocole était initialement destiné à l'échange de documents hypertextes, maintenant ses capacités ont été considérablement étendues (en particulier, des fonctionnalités de support de streaming ont été ajoutées).

HTTP est un protocole client-serveur typique, les messages sont échangés selon le schéma "requête-réponse" sous la forme de commandes ASCII. Une particularité du protocole HTTP est la possibilité de spécifier dans la requête et la réponse comment une même ressource est représentée par différents paramètres : format, encodage, langue, etc. C'est grâce à la possibilité de spécifier la méthode d'encodage du message que le client et serveur peut échanger des données binaires, bien que ce protocole soit du texte.

HTTP est un protocole de couche application mais est également utilisé comme "transport" pour d'autres protocoles d'application tels que SOAP, XML-RPC, WebDAV.

Le protocole HTTP définit une méthode d'interaction requête-réponse entre un programme client et un programme serveur au sein de la technologie. à l'échelle mondiale La toile.

Pour charger une page Web dans un navigateur client, il envoie un message installé sur l'ordinateur serveur programme spécial, appelé http-server, la requête correspondante et traite les données reçues de celui-ci. Dans ce cas, les fonctions du navigateur sont de demander une certaine page au serveur, de l'obtenir et de l'afficher sur l'écran de l'utilisateur. Le serveur, d'autre part, accepte la demande, recherche le document demandé et donne au client soit le contenu du fichier trouvé, soit un message d'erreur si un tel fichier n'a pas été trouvé ou si l'accès à celui-ci a été refusé pour une raison quelconque. Un point important pour comprendre ce processus est que le serveur http n'analyse pas le contenu du document transmis. En gros, le serveur http ne se soucie pas du contenu du fichier demandé, il ne fait que le transmettre au navigateur, et le navigateur s'occupe déjà de tout le travail de structuration et d'affichage des informations reçues.

La recherche de la page demandée est effectuée dans un certain répertoire, qui est attribué sur l'ordinateur serveur de ce site - un lien vers ce répertoire est présent dans l'adresse saisie par l'utilisateur. Dans le cas où la demande n'est pas adressée à un document spécifique, mais au site dans son ensemble, le serveur http remplace automatiquement la soi-disant "page de démarrage" au lieu du nom du fichier transféré, qui est nommé index.htm ou index.html (dans certains cas - default.htm ou default.html). Ce document doit se trouver dans le répertoire racine désigné pour héberger votre site, ou, sauf indication contraire, dans un répertoire appelé WWW. Tous les autres fichiers peuvent être placés soit dans le même répertoire, soit dans des répertoires imbriqués, ce qui est parfois pratique, notamment lorsque le site contient plusieurs rubriques ou rubriques thématiques.

En plus des sous-dossiers que vous créez, dans lesquels vous êtes libre de placer presque tout le contenu dont vous avez besoin, le répertoire du serveur contient généralement plusieurs autres répertoires qui doivent être mentionnés séparément. Premièrement, il s'agit du dossier CGI-BIN, où se trouvent les scripts CGI et autres applications interactives lancées depuis votre site, ainsi que plusieurs répertoires de services nécessaires au fonctionnement normal du serveur. Au stade initial, il ne faut tout simplement pas y prêter attention. Parfois, dans le même répertoire où index.html est stocké, il y a une ligne fichiers supplémentaires: not_found.html - le document qui est affiché si le serveur http n'a pas pu trouver le fichier demandé par l'utilisateur, interdit.html - affiché comme un message d'erreur si l'accès au document demandé est refusé, et enfin robots.txt - le fichier , qui décrit précisément les règles d'indexation de votre site par les moteurs de recherche.

Dans la plupart des cas, et en particulier lors de la publication d'une page d'accueil sur des serveurs offrant un hébergement gratuit, les utilisateurs se voient refuser l'accès aux répertoires de services et au dossier CGI-BIN, et la modification du contenu des fichiers not_found et disabled.html est également impossible. Cela doit être pris en compte si vous envisagez d'inclure dans votre ressource un contenu interactif nécessitant au moins la possibilité de placer des fichiers dans l'un des dossiers de service. Dans certains cas, il se peut que vous ne soyez pas autorisé à créer des répertoires imbriqués sur le serveur, auquel cas l'utilisateur devra se contenter d'un seul répertoire réservé à vos besoins.

De ce qui précède, il devient clair que le navigateur client ne peut recevoir et traiter les informations du serveur, et les placer et les modifier que si le téléchargement de fichiers sur le serveur est implémenté sur la base du protocole HTTP à l'aide de scripts CGI spéciaux inclus dans le serveur web.-interface. Dans tous les autres cas, vous devez utiliser le soi-disant serveur ftp, auquel vous pouvez transférer les fichiers nécessaires à l'aide d'un logiciel spécial, en les téléchargeant automatiquement dans le répertoire désigné pour votre site. Dans les deux cas, vous aurez besoin de connaître votre identifiant et votre mot de passe pour accéder au système. Il convient également de rappeler que la plupart des programmes serveur (en particulier, Apache pour les plates-formes compatibles UNIX) font la distinction entre les caractères minuscules et majuscules, de sorte que tous les noms de fichiers et leurs extensions doivent être écrits en lettres minuscules pour éviter les erreurs, et toujours en latin. Ce dernier est dû à des différences dans le traitement des encodages en langue russe, typiques de certains serveurs.

Le protocole HTTP fonctionne comme suit : le programme client établit une connexion TCP avec le serveur (le numéro de port standard est 80) et lui adresse une requête HTTP. Le serveur traite cette demande et envoie une réponse HTTP au client.

L'interaction entre le client et le serveur Web s'effectue par l'échange de messages. Les messages HTTP sont divisés en requêtes client-serveur et en réponses serveur-client.

Les messages de requête et de réponse ont un format commun. Les deux types de messages ressemblent à ceci : vient d'abord une ligne de départ, puis éventuellement un ou plusieurs champs d'en-tête, également appelés en-têtes, puis une ligne vide (c'est-à-dire une ligne composée de caractères CR et LF), indiquant la fin de l'en-tête champs, puis éventuellement le corps du message :

chaîne initiale

champ d'en-tête 1

champ d'en-tête 2

champ d'en-tête N

Corps du message

En-têtes HTTP

Le format de la chaîne initiale du client et du serveur diffère et sera discuté ci-dessous. Il existe quatre types d'en-têtes :

Les en-têtes généraux (general-headers), qui peuvent être présents à la fois dans la requête et dans la réponse ;

Les en-têtes de requête (request-headers), qui ne peuvent être présents que dans la requête ;

Les en-têtes de réponse (response-headers), qui ne peuvent être présents que dans la réponse ;

En-têtes d'entité qui font référence au corps du message et décrivent son contenu.

Chaque en-tête se compose d'un titre, d'un caractère deux-points ":" et d'une valeur. Les rubriques les plus importantes sont présentées dans le tableau 1.

Tableau 1

En-têtes HTTP

entête But
Titres d'objet
Autoriser Répertorie les méthodes prises en charge par le serveur
encodage de contenu La façon dont le corps du message est encodé, par exemple pour réduire la taille
longueur du contenu Longueur du message en octets
type de contenu Contient la désignation du type de contenu MIME de la réponse. Selon la valeur Content-Type, le navigateur traite la réponse comme une page HTML, image gif ou jpeg, en tant que fichier à enregistrer sur le disque, ou autre, et prend les mesures appropriées. Certains types de contenu : text/html - texte au format HTML (page Web) ; text/plain - texte brut (similaire à "notepad"); image/jpeg - image au format JPEG ; image/gif - identique, au format GIF ; Il peut également transmettre un encodage pour les données textuelles. Par exemple : charset=windows-1251 charset=koi8-rus Content-Length - longueur du contenu de la réponse en octets (taille du fichier). Dernière modification - date et heure de la dernière modification du document.
ETag Une balise de ressource unique sur le serveur qui vous permet de comparer les ressources
Expire Date et heure auxquelles la ressource sur le serveur sera modifiée et doit être récupérée à nouveau
Dernière modification Date et heure de la dernière modification du contenu
En-têtes de réponse
Âge Nombre de secondes pour réessayer la requête pour obtenir un nouveau contenu
lieu L'URI de la ressource à laquelle accéder pour obtenir le contenu
Réessayer-Après Date et heure ou nombre de secondes après lesquelles la demande doit être réessayée pour recevoir une réponse réussie
serveur Le nom du logiciel serveur qui a envoyé la réponse
En-têtes de requête
J'accepte Une liste des types de contenu pris en charge par le navigateur par ordre de préférence pour ce navigateur, par exemple : Accept : image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/ msword, application/vnd.ms-powerpoint, */* Ceci est évidemment nécessaire dans le cas où le serveur peut émettre le même document dans des formats différents. La valeur de ce paramètre est principalement utilisée par les scripts CGI pour générer une réponse adaptée à un navigateur donné.
Accepter le jeu de caractères Encodages de caractères dans lesquels le client peut accepter le contenu textuel
Accepter l'encodage La façon dont le serveur peut encoder le message
Héberger Hôte et numéro de port à partir desquels le document est demandé
Si-Modifié-Depuis Si-Correspondance Si-Aucune-Correspondance Si-Plage Si-Non modifié-Depuis En-têtes de requête pour l'accès conditionnel à une ressource
Varier Demander une partie d'un document
Agent utilisateur Le nom du logiciel client - la valeur est le « nom de code » du navigateur, par exemple : Mozilla/4.0 (compatible ; MSIE 5.0 ; Windows 95 ; DigExt)
Rubriques générales
connexion Connexion (connexion) - peut prendre les valeurs Keep-Alive et close. Keep-Alive ("keep alive") signifie qu'après l'émission de ce document, la connexion avec le serveur n'est pas interrompue et que d'autres requêtes peuvent être émises. La plupart des navigateurs fonctionnent en mode Keep-Alive, car il vous permet de "télécharger" une page html et des images pour celle-ci en une seule connexion au serveur. Une fois défini, Keep-Alive persiste jusqu'à la première erreur ou est explicitement spécifié dans la prochaine connexion : demande de fermeture. close - La connexion est fermée après la réponse à cette requête.
Date Date et heure de génération du message
pragmatique Commandes spéciales spécifiques à l'implémentation concernant le contenu en cours de transfert
Codage de transfert Comment le message est encodé lors de la transmission

Dans certains en-têtes, la valeur est une date et une heure. Ils doivent être au format décrit dans la RFC 1123, par exemple :

Le corps du message contient les informations réellement transmises - la charge utile du message. Le corps du message est une séquence d'octets (octets). Le corps du message peut être codé, avec la méthode de codage spécifiée dans l'en-tête de l'objet Content-Encoding.

Un message de requête d'un client à un serveur se compose d'une ligne de requête, d'en-têtes (général, requêtes, objet) et éventuellement d'un corps de message.

La chaîne de requête commence par une méthode, suivie de l'ID de ressource demandée, de la version du protocole et des caractères de fin de ligne :

<Метод> <Идентификатор> <Версия HTTP>

La méthode spécifie la méthode à appliquer à la ressource demandée. Par exemple, la méthode GET indique que le client souhaite obtenir le contenu de la ressource. L'identifiant identifie la ressource demandée. La version HTTP est indiquée par une chaîne comme celle-ci :

http/<версия>.<подверсия>

Méthodes du protocole HTTP

Considérez les méthodes de base du protocole HTTP.

La méthode OPTIONS demande des informations sur les options de connexion (par exemple, les méthodes, les types de document, les codages) que le serveur prend en charge pour la ressource demandée. Cette méthode permet au client de déterminer les options et/ou les exigences associées à la ressource, ou les capacités du serveur, sans effectuer aucune action sur la ressource ou lancer un téléchargement de celle-ci.

Si la réponse du serveur n'est pas un message d'erreur, alors les en-têtes d'entité contiennent des informations qui peuvent être considérées comme des options de connexion. Par exemple, l'en-tête Allow répertorie toutes les méthodes prises en charge par le serveur pour une ressource donnée.

Si l'identifiant de ressource demandé est un astérisque ("*"), alors la demande OPTIONS est destinée à s'adresser au serveur dans son ensemble.

Si l'identificateur de ressource demandé n'est pas un astérisque, la demande OPTIONS s'applique aux options disponibles lors de la connexion à la ressource spécifiée.

La méthode GET vous permet d'obtenir toutes les informations relatives à la ressource demandée. Dans la plupart des cas, si l'identifiant de ressource demandé pointe vers un document (par exemple, Document texte, image graphique, vidéo), alors le serveur renvoie le contenu de ce document (le contenu du fichier). Si la ressource demandée est une application génératrice de données (programme), les données générées sont renvoyées dans le corps du message de réponse plutôt qu'une image binaire de l'exécutable. Ceci est utilisé, par exemple, lors de la création d'applications CGI. Si l'identifiant de la ressource demandée pointe vers un répertoire (répertoire, dossier), alors, selon les paramètres du serveur, soit le contenu du répertoire (liste des fichiers), soit le contenu d'un des fichiers se trouvant dans ce répertoire (généralement index.html ou default.htm). Dans ce dernier cas, le nom du dossier peut être spécifié avec ou sans le caractère "/" à la fin. En l'absence de ce symbole à la fin de l'identifiant, le serveur émet l'une des réponses de redirection (avec les codes d'état 301 ou 302).

Une distinction est faite entre "GET conditionnel", dans lequel le message de demande inclut les en-têtes de demande If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match ou If-Range. La méthode GET conditionnelle demande le transfert d'un objet uniquement s'il satisfait aux conditions décrites dans les en-têtes fournis. La méthode GET conditionnelle est destinée à réduire la charge inutile du réseau, puisqu'elle permet de ne pas recharger les données déjà enregistrées par le client.

Une distinction est également faite entre "GET partiel", dans lequel le message de requête comprend un en-tête de requête Range. Un GET partiel demande le transfert d'une partie seulement d'un objet. La méthode GET partielle est destinée à réduire la charge réseau inutile en ne demandant qu'une partie d'un objet lorsque l'autre partie a déjà été chargée par le client. La valeur de l'en-tête Range est la plage d'octets à recevoir. Les octets sont numérotés à partir de 0. Les octets de début et de fin d'une plage sont séparés par un caractère "-". Si vous avez besoin d'obtenir plusieurs plages, elles sont répertoriées séparées par des virgules.

La méthode HEAD est identique à GET, sauf que le serveur ne renvoie pas de corps de message dans la réponse. Les méta-informations contenues dans les en-têtes HTTP d'une réponse à une requête HEAD sont identiques aux informations fournies en réponse à une requête GET. Cette méthode peut être utilisée pour obtenir des informations sur l'objet de requête sans passer directement le corps de l'objet. La méthode HEAD est souvent utilisée pour tester les liens hypertextes.

La méthode POST est utilisée pour une requête dans laquelle le serveur adressé prend les données incluses dans le corps du message (objet) de la requête et les envoie pour traitement à l'application spécifiée comme ressource demandée. POST est conçu pour être une méthode commune pour implémenter les fonctions suivantes :

Annotation des ressources existantes ;

Publier un message sur un babillard électronique (BBS), des groupes de discussion, des listes de diffusion ou un groupe d'articles similaires ;

Passer un bloc de données, tel que le résultat d'une saisie dans un formulaire, à un processus de traitement ;

Exécution de requêtes aux bases de données (DB);

En fait, la fonction réalisée par la méthode POST est déterminée par l'application pointée par l'identifiant de la ressource demandée. Avec la méthode GET, la méthode POST est utilisée lors de la création d'applications CGI. Le navigateur peut générer des requêtes avec la méthode POST lors de la soumission de formulaires. Pour ce faire, l'élément FORM du document HTML contenant le formulaire doit avoir un attribut METHOD avec une valeur de POST.

Une action effectuée par la méthode POST peut effectuer une action sur le serveur et ne transmettre aucun contenu à la suite de l'opération. Dans ce cas, selon que la réponse inclut ou non un corps de message décrivant le résultat, le code d'état de la réponse peut être 200 (OK) ou 204 (Pas de contenu).

Si la ressource sur le serveur a été créée, la réponse contient un code d'état 201 (Created) et inclut un en-tête de réponse Location.

Le corps du message passé dans la requête avec la méthode PUT est stocké sur le serveur, et l'identifiant de la ressource demandée sera l'identifiant du document enregistré. Si l'identifiant de la ressource demandée pointe vers une ressource déjà existante, alors l'objet inclus dans le corps du message est traité comme une version modifiée de la ressource située sur le serveur. Si une nouvelle ressource est créée, le serveur en informe l'agent utilisateur au moyen d'une réponse avec un code d'état de 201 (Created, Created).

La différence fondamentale entre les méthodes POST et PUT est signification différente l'identifiant de la ressource demandée. L'URI dans une requête POST identifie la ressource qui gère l'objet inclus dans le corps du message. Cette ressource peut être une application qui reçoit les données. En revanche, un URI dans une demande PUT identifie l'entité incluse dans la demande comme le corps du message, c'est-à-dire que l'agent utilisateur attribue cet URI à la ressource incluse.

La méthode DELETE demande au serveur de supprimer la ressource qui a l'identifiant demandé. Une demande avec cette méthode peut être rejetée par le serveur si l'utilisateur n'a pas l'autorisation de supprimer la ressource demandée.

La méthode TRACE est utilisée pour renvoyer une requête transmise au niveau du protocole HTTP. Le destinataire de la demande (le serveur Web) renvoie le message reçu au client sous la forme d'un corps d'objet de réponse avec un code d'état de 200 (OK). Une requête TRACE ne doit pas contenir de corps de message.

TRACE permet au client de voir ce que le serveur reçoit à l'autre extrémité et d'utiliser ces informations pour des tests ou des diagnostics.

Si la demande aboutit, la réponse contient le message de demande entier dans le corps du message de réponse, et l'en-tête Content-Type a la valeur "message/http".

Codes de réponse

Après réception et interprétation du message de demande, le serveur répond par un message de réponse HTTP.

La première ligne de la réponse est la Status-Line. Il se compose de la version du protocole, d'un code d'état numérique, d'une phrase explicative, séparés par des espaces et de caractères de fin de ligne :

<Версия HTTP> <Код состояния> <Поясняющая фраза>

La version du protocole a la même valeur que dans la requête.

L'élément Status-Code est un code entier à trois chiffres (trois chiffres) du résultat de la compréhension et de la satisfaction de la demande. La Reason-Phrase est une courte description textuelle du code d'état. Le code d'état est pour le traitement du logiciel et la phrase explicative est pour les utilisateurs.

Le premier chiffre du code d'état détermine la classe de la réponse. Les deux derniers chiffres n'ont pas de rôle spécifique dans la classification. Il y a 5 valeurs pour le premier chiffre :

1xx : Codes d'information - demande reçue, le traitement se poursuit.

2xx : Codes de réussite - L'action a été reçue, comprise et traitée avec succès.

3xx : Codes de redirection - D'autres mesures doivent être prises pour compléter la demande.

4xx : Codes d'erreur client - La demande contient une erreur de syntaxe ou ne peut pas être traitée.

5xx : Codes d'erreur du serveur - Le serveur est incapable de répondre à une demande valide.

Les phrases de raison pour chaque code d'état sont répertoriées dans la RFC 2068 et sont recommandées mais peuvent être remplacées par des phrases équivalentes sans affecter le protocole. Par exemple, dans les versions russes localisées des serveurs HTTP, ces phrases sont remplacées par des phrases russes. Le tableau 2 montre les codes de réponse du serveur HTTP.

Tableau 2

Codes de réponse du serveur HTTP

Le code Phrase explicative selon RFC 2068 Phrase explicative équivalente en russe
1xx : codes d'information
Continuez Continuez
2xx : codes de réussite
d'accord d'accord
Créé Créé
Pas de contenu Pas de contenu
Réinitialiser le contenu Réinitialiser le contenu
Contenu partiel Contenu partiel
3xx : codes de redirection
Déplacé temporairement Temporairement relocalisé
Non modifié Non modifié
4xx : Codes d'erreur client
Mauvaise demande Demande brisée
Non autorisé Non autorisé
pas trouvé Pas trouvé
Méthode Non Autorisée Méthode Non Autorisée
Délai d'expiration de la demande La demande a expiré
Conflit Conflit
Longueur requise Longueur requise
Entité de requête trop grande L'objet de la requête est trop grand
5xx : codes d'erreur du serveur
Erreur interne du serveur Erreur interne du serveur
Pas mis en œuvre Pas mis en œuvre
Service indisponible Le service est indisponible
Version HTTP non prise en charge Version de HTTP non prise en charge

La ligne d'état est suivie des en-têtes (général, réponse et objet) et éventuellement du corps du message.

L'une des fonctions les plus importantes d'un serveur Web est de fournir un accès à une partie du système de fichiers local. Pour ce faire, un certain répertoire est spécifié dans les paramètres du serveur, qui est la racine de ce serveur. Publier un document, c'est-à-dire le faire à la disposition des utilisateurs, qui ont "visité" ce serveur (après s'être connecté via HTTP), doivent copier ce document dans le répertoire racine du serveur Web ou dans l'un de ses sous-répertoires. Lors de la connexion via le protocole HTTP, un processus est créé sur le serveur avec des droits d'utilisateur, qui, en règle générale, n'existe pas dans la réalité, mais est spécialement créé pour afficher les ressources du serveur. Définition des droits et autorisations cet utilisateur Vous pouvez contrôler l'accès aux ressources Web.

Considérer l'exemple le plus simple Requête HTTP. Si nous tapons l'adresse http://yandex.ru dans la fenêtre d'adresse du navigateur, le navigateur déterminera l'adresse IP du serveur yandex.ru et lui enverra la requête HTTP suivante sur le 80e port :

GET http://yandex.ru/ HTTP/1.0

Accepter : image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Accepter-Langue : en

Cookie : yandexuid=2464977781018373381

Agent utilisateur : Mozilla/4.0 (compatible ; MSIE 5.5 ; Windows 98)
Hébergeur : yandex.ru

Référent: narod.ru

Connexion proxy : Keep Alive

La demande est envoyée sous forme de texte non crypté. La partie la plus importante de la requête se trouve sur la première ligne : il s'agit du type de requête (GET), de l'URL du document demandé (http://yandex.ru) et de la version du protocole HTTP (HTTP/1.0) . Les paramètres de requête sont répertoriés ci-dessous. Chaque ligne correspond à un paramètre. La ligne commence par le nom du paramètre, suivi de deux-points et de la valeur du paramètre.

Accepter - le type de données que le navigateur peut accepter (en codage MIME).

Accept-Language est la langue préférée dans laquelle le navigateur souhaite accepter les données. User-Agent - le type de programme qui a envoyé la demande.

Hôte - Nom DNS (ou IP) de l'hôte auquel la demande est adressée.

Cookie - cookies (données stockées par le serveur sur le disque local du client lors de la dernière visite de cet hôte).

Référent - l'hôte à partir duquel nous envoyons la demande. Ainsi, par exemple, si nous sommes sur la page http://narod.ru et que nous cliquons sur le lien http://yandex.ru, la demande sera envoyée à l'hôte yandex.ru et le champ de demande de référence contiendra le nom d'hôte narod.ru.

L'ensemble des paramètres de requête n'est pas fixe. En plus de ce qui précède, il peut y avoir d'autres paramètres.

Les paramètres les plus intéressants sont le referer et le cookie. Ces paramètres sont principalement utilisés pour identifier l'utilisateur par le serveur.

La requête GET peut contenir des données transmises du client au serveur. Ils sont transmis directement via une URL en utilisant le protocole CGI. Les données sont séparées de l'URL par un "?" et sont reliés par le signe "&":

AVOIR ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

Ce type de transfert de données vers le serveur est pratique, mais a des limites sur le volume. Les tableaux de données trop volumineux ne peuvent pas être transmis via URL. A ces fins, il existe un autre type de requête : une requête POST. Une requête POST est très similaire à une requête GET, à la seule différence que les données de la requête POST sont transmises séparément de l'en-tête de requête lui-même :

Le corps de la requête doit être séparé de l'en-tête par une ligne vide. Si le serveur rencontre une chaîne vide dans une requête POST, alors tout ce qui suit est considéré comme le corps de la requête (données transmises). Notez ce qui suit : le format des données dans le corps de la requête POST est arbitraire. Bien que le format CGI soit le plus couramment utilisé, il n'est pas obligatoire. De plus, une requête POST ne nécessite pas de corps de requête et peut également transmettre des données via une URL.

En plus du format CGI, parfois pour transférer de grandes quantités d'informations (par exemple, des fichiers), utilisez le soi-disant. format multipart (le format des données transmises est déterminé par le paramètre Content-Type) :

Les navigateurs modernes contiennent des outils permettant aux développeurs Web d'obtenir des informations sur les demandes de publication envoyées. Si vous avez besoin de regarder les en-têtes de quelques requêtes seulement, leur utilisation sera plus facile et plus rapide que d'autres méthodes.

Si vous utilisez Firefox, vous pouvez utiliser sa console Web. Il affiche les en-têtes de requête et le contenu des cookies transmis. Pour le lancer, ouvrez le menu du navigateur, cliquez sur l'élément "Développement Web" et sélectionnez "Console Web". Dans le panneau qui apparaît, activez le bouton "Réseau". Entrez le nom de la méthode dans le champ de filtre - post. Selon vos objectifs, cliquez sur le bouton du formulaire qui envoie la demande requise ou actualisez la page. La console affichera la demande soumise. Cliquez dessus avec votre souris pour voir plus de détails.

Navigateur Google Chrome dispose de puissants outils de débogage. Pour les utiliser, cliquez sur l'icône en forme de clé à molette, puis développez l'élément "Personnaliser et contrôler Google Chrome". Sélectionnez "Outils" et lancez "Outils de développement". Dans la barre d'outils, sélectionnez l'onglet Réseau et soumettez la demande. Trouvez la demande requise dans la liste et cliquez dessus pour afficher les détails.

DANS Navigateur Opera il existe des outils intégrés pour les développeurs d'Opera Dragonfly. Pour les lancer, cliquez avec le bouton droit sur la page souhaitée et sélectionnez l'élément "Inspecter l'élément" dans le menu contextuel. Allez dans l'onglet "Réseau" des outils de développement et soumettez la demande souhaitée. Recherchez-le dans la liste et développez-le pour examiner les en-têtes et les réponses du serveur.

Internet Explorer 9 contient une suite appelée "F12 Developer Tools" qui fournit des informations détaillées sur les demandes complétées. Ils sont lancés en appuyant sur la touche F12 ou en utilisant le menu "Outils" contenant l'item du même nom. Pour visualiser la demande, rendez-vous dans l'onglet "Réseau". Recherchez une requête donnée dans le résumé et double-cliquez pour développer les détails.

Navigateurs Chrome et Internet Explorer 9 contiennent des outils intégrés qui vous permettent d'examiner en détail la demande de publication soumise. Pour plus de détails, utilisez-les ou Firefox avec le plugin Firebug installé. C'est très pratique pour examiner fréquemment les requêtes, par exemple, lors du débogage de sites Web.

Si vous souhaitez voir une requête envoyée par un programme autre que le navigateur, utilisez le débogueur HTTP de Fiddler. Il agit comme un serveur proxy et intercepte les requêtes de n'importe quel programme et fournit des informations très détaillées sur leurs en-têtes et leur contenu.

URI (Identificateur de ressource uniforme) est un identifiant de ressource uniforme (uniforme). URI - une chaîne de caractères qui permet d'identifier n'importe quelle ressource : un document, une image, un fichier, un service, une boîte e-mail, etc. Tout d'abord, nous parlons bien sûr des ressources d'Internet et du monde entier La toile. L'URI fournit un moyen simple et extensible d'identifier les ressources. L'extensibilité d'URI signifie qu'il existe déjà plusieurs schémas d'identification dans les URI, et d'autres seront créés à l'avenir.

Relation entre URI, URL et URN

Diagramme de Venn montrant des sous-ensembles du schéma d'URI : URL et URN.

Un URI est soit une URL, soit un URN, soit les deux.

  • Une URL est un URI qui, en plus d'identifier une ressource, fournit également des informations sur l'emplacement de cette ressource.
  • Un URN est un URI qui identifie uniquement une ressource dans un espace de noms spécifique (respectivement, dans un contexte spécifique), mais ne spécifie pas son emplacement. Par exemple, l'URN urn:ISBN:0-395-36341-1 est un URI qui pointe vers la ressource (livre) 0-395-36341-1 dans l'espace de noms ISBN, mais contrairement à une URL, un URN ne pointe pas vers le emplacement de cette ressource : il ne dit pas dans quel magasin elle peut être achetée ni sur quel site la télécharger.

Comme une URI n'indique pas toujours comment obtenir une ressource, contrairement à une URL, mais ne fait que l'identifier, cela permet de décrire à l'aide de RDF (Resource Description Framework) des ressources qui ne peuvent pas être obtenues via Internet (par exemple, une personne, une voiture, une ville, etc.).

Histoire

En 1990, à Genève, en Suisse, dans l'enceinte du Conseil européen pour la recherche nucléaire, le scientifique britannique Tim Berners-Lee a inventé le localisateur de ressources URL. Étant donné que l'URL est le sous-ensemble le plus utilisé de l'URI, la même année 1990 est considérée comme l'année de naissance de l'URI. Mais à proprement parler, le concept d'URI n'a été documenté qu'en juin 1994 dans la RFC 1630.

Une nouvelle version de l'URI a été définie en 1998 dans la RFC 2396, à la même époque le mot Universel le nom a été changé en Uniforme.

désavantages

L'URL était une innovation fondamentale sur Internet, de sorte que les principes d'URI ont été documentés pour être entièrement compatibles avec les URL. C'est de là que vient le gros inconvénient de l'URI, hérité de l'URL. Les URI, comme les URL, ne peuvent utiliser qu'un ensemble limité de Caractères latins et des signes de ponctuation (encore plus petits qu'en ASCII). En d'autres termes, si nous voulons utiliser des caractères cyrilliques, ou des hiéroglyphes, ou, disons, des caractères français spécifiques dans l'URI, nous devrons encoder l'URI de la même manière que Wikipedia encode les URL avec des caractères Unicode. Par exemple, une ligne comme :

https://en.wikipedia.org/wiki/cyrillique

encodé dans l'URL comme :

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

Étant donné que les lettres de tous les alphabets sont soumises à une telle transformation, à l'exception de l'alphabet latin utilisé en anglais, les URI avec des mots dans d'autres langues (même européennes) perdent leur capacité à être perçues par les gens. Et cela est en contradiction flagrante avec le principe d'internationalisme proclamé par toutes les principales organisations de l'Internet, y compris le W3C et l'ISOC. Ce problème est destiné à être résolu par la norme IRI. Identificateur de ressource internationalisé) sont des identificateurs de ressources internationaux dans lesquels les caractères Unicode pourraient être utilisés sans problème et qui n'enfreindraient pas les droits d'autres langues. En outre, le créateur de l'URI, Tim Berners-Lee, a déclaré que le système de nom de domaine sous-jacent à l'URL est Mauvaise Décision, qui impose une architecture hiérarchique des ressources qui n'est pas adaptée au web hypertexte.

Structure d'URI

URI = [schéma ":"] hiérarchique - partie [ "?" requête ] [fragment "#" ]

Dans cette entrée :

Schème

schéma d'accès aux ressources (indique souvent un protocole réseau), par exemple http, ftp, file, ldap, mailto, urn

partie hiérarchique

contient des données, généralement organisées sous une forme hiérarchique, qui, associées à des données dans un composant non hiérarchique enquête, sont utilisés pour identifier une ressource dans le cadre d'un schéma d'URI. D'habitude partie hiérarchique contient le chemin vers la ressource (et éventuellement, avant lui, l'adresse du serveur sur lequel elle se trouve) ou l'identifiant de la ressource (dans le cas d'un URN).

Enquête

ce composant URI facultatif est décrit ci-dessus.

Fragment

(également facultatif)

Permet d'identifier indirectement une ressource secondaire en se référant à la ressource principale et en spécifiant des informations supplémentaires. Une ressource identifiable secondaire peut être une partie ou un sous-ensemble d'une ressource primaire, une représentation de celle-ci ou une autre ressource définie ou décrite par une telle ressource.

Analyse de la structure URI. Pour l'URI dit "parsing" (eng. analyse), c'est-à-dire pour décomposer un URI en ses composants et ensuite les identifier, il est plus pratique d'utiliser le système d'expressions régulières qui est maintenant disponible dans presque tous les langages de programmation modernes. La RFC 3986 recommande d'utiliser le modèle suivant pour analyser un URI :

Ce modèle comprend les 9 groupes indiqués ci-dessus par des nombres (voir Expressions régulières pour en savoir plus sur les modèles et les groupes), qui analysent le plus complètement et avec précision la structure URI typique, où :

  • groupe 2 - régime,
  • groupe 4 - source,
  • groupe 5 - chemin,
  • groupe 7 - demande,
  • groupe 9 - fragment.

Ainsi, si vous utilisez ce modèle pour analyser, par exemple, un tel URI typique :

http://www.ics.uci.edu/pub/ietf/uri/#Related

alors les 9 groupes de motifs ci-dessus produiront respectivement les résultats suivants :

  1. http :
  2. //www.ics.uci.edu
  3. www.ics.uci.edu
  4. /pub/ietf/uri/
  5. pas de résultat
  6. pas de résultat
  7. #En rapport
  8. en relation

Exemples d'URI :

URI absolus

  • https://ru.wikipedia.org/wiki/URI
  • ftp://ftp.is.co.za/rfc/rfc1808.txt
  • file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
  • fichier:///C:/fichier.wsdl
  • file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
  • ldap:///c=GB?objectClass?one
  • mailto : [courriel protégé]
  • siroter: [courriel protégé]
  • news:comp.infosystems.www.servers.unix
  • data:text/plain;charset=iso-8859-7,%be%be%be
  • tél. :+1-816-555-1212
  • telnet://192.0.2.16:80/
  • urn:oasis:names:specification:docbook:dtd:xml:4.1.2

2) URI relatifs

  • /relative/URI/with/absolute/path/to/resource.txt
  • //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
  • relatif/chemin/vers/ressource.txt
  • ../../../ressource.txt
  • ressource.txt
  • /resource.txt#frag01
  • #frag01

[chaîne vide] - équivalent à l'analyse de l'identifiant par l'analyseur avec le résultat [chaîne vide], c'est-à-dire que le lien mène à l'objet par défaut dans le schéma par défaut

Service DNS

DNS - système de nom de domaine. Les noms de domaine DNS sont des synonymes d'adresse IP, tout comme les noms du carnet d'adresses de votre téléphone sont des synonymes les numéros de téléphone. Ce sont des caractères, pas des chiffres ; ils sont plus pratiques pour la mémorisation et l'orientation ; ils sont porteurs de sens. www.irnet.ru → Tables DNS →193.232.70.36 Les noms de domaine sont également uniques, c'est-à-dire Il n'y a pas deux noms de domaine identiques dans le monde. Les noms de domaine, contrairement aux adresses IP, sont facultatifs, ils s'achètent séparément.

Riz. 2. Hiérarchie dans le système DNS.

Les adresses indiquées sur les enveloppes lors de la livraison des lettres par courrier ordinaire sont également uniques. Il n'y a pas de pays dans le monde avec le même nom. Et si les noms des villes sont parfois répétés, alors en combinaison avec la division en unités administratives plus grandes telles que les districts et les régions, ils deviennent uniques. Et les noms de rue ne doivent pas être répétés dans la même ville. Ainsi, une adresse basée sur des noms géographiques et administratifs identifie de manière unique une destination. Les domaines ont une hiérarchie similaire. Les noms de domaine sont séparés les uns des autres par des points : lingvo.yandex.ru, krkime.com.

DNS a les caractéristiques suivantes :

  • Répartition de l'administration. Différentes personnes ou organisations sont responsables de différentes parties de la structure hiérarchique.
  • Répartition du stockage des informations. Chaque nœud de réseau doit nécessairement stocker uniquement les données qui sont incluses dans son domaine de responsabilité, et (éventuellement) adresses serveurs DNS racine.
  • Mise en cache des informations. Nouer peut être stocker une certaine quantité de données ne relevant pas de leur domaine de responsabilité afin de réduire la charge sur le réseau.
  • Structure hiérarchique, dans lequel tous les nœuds sont combinés dans un arbre, et chaque nœud peut soit déterminer indépendamment le travail des nœuds en aval, soit déléguer(les transmettre) à d'autres nœuds.
  • Réservation. Plusieurs serveurs (généralement) sont responsables du stockage et de la maintenance de leurs nœuds (zones), séparés à la fois physiquement et logiquement, ce qui garantit la sécurité des données et la poursuite du travail même si l'un des nœuds tombe en panne.

Niveaux de domaine. Il existe trois niveaux de domaines.

Domaines premier ou niveau supérieur sont divisés en deux groupes :

1) Ce sont des domaines avec une affiliation territoriale, par exemple : .ru .by .ua .de .us, etc. C'est-à-dire que ce sont des domaines qui sont attribués à un pays particulier. En les utilisant, vous pouvez, par exemple, déterminer à quel pays appartient un site particulier.

2) Le deuxième groupe de domaines de premier niveau sont des domaines ayant un objectif spécifique. Par exemple : .com - pour les organisations commerciales, .info - pour les sites d'information, .tv - pour les sociétés de télévision, etc. Ces domaines peuvent déterminer l'orientation spécifique du site. Bien que, à vrai dire, ces derniers temps, ils aient été de plus en plus utilisés à toutes fins et souvent ne respectent pas leur objectif.

Les domaines de premier niveau ne peuvent pas être utilisés comme adresse de votre site. Ils servent à créer des domaines deuxième niveau , vous pouvez donc enregistrer un domaine de second niveau sur n'importe lequel des domaines de premier niveau. Le domaine de second niveau se compose des éléments suivants : www.nom_du_site.domaine de premier niveau. Par exemple : www.webmastermix.ru. Il est recommandé d'utiliser des noms de domaine de second niveau pour l'adresse du site Web. Ils sont mieux lus et retenus par les gens, ainsi que perçus par les moteurs de recherche. Par conséquent, la plupart des sites ont des noms de domaine de ce niveau particulier.

De plus, il existe des domaines troisième niveau . Ils sont créés sur la base de domaines de second niveau. Le domaine de troisième niveau ressemble à ceci : www.forum.webmastermix.ru. En enregistrant un domaine de deuxième niveau, vous pouvez créer indépendamment autant de domaines de troisième niveau que vous le souhaitez. Vous pouvez enregistrer un nom de domaine pour votre site en utilisant des services spéciaux.

TECHNOLOGIES WEB : HTML, JAVASCRIPT

La première partie du bloc didactique au-dessus de ce thème était consacrée aux technologies Internet. Maintenant, nous commençons à étudier les technologies utilisées dans le World Wide Web, ou les technologies Web.

Vous devez d'abord comprendre les concepts de base des technologies Web : un site Web et une page Web. Une page Web est la plus petite unité logique du World Wide Web, qui est un document identifié de manière unique par une URL unique. Un site Web est un ensemble de pages Web thématiquement liées situées sur le même serveur et détenues par le même propriétaire. Dans un cas particulier, un site Web peut être représenté par une seule page Web. Le World Wide Web est la collection de tous les sites Web.

La base de l'ensemble du World Wide Web est le langage de balisage hypertexte HTML - Hyper Text Markup Language (Fig. 3). Il sert au balisage logique (sémantique) d'un document (page web). Il est parfois utilisé à mauvais escient pour contrôler l'affichage du contenu d'une page Web sur un écran ou lors de sa sortie sur une imprimante, ce qui est fondamentalement contraire à l'idéologie adoptée dans World Wide Web.

Riz. 3. Technologies Internet

Les feuilles de style en cascade (CSS) sont conçues pour contrôler l'affichage du contenu des pages Web. CSS est à bien des égards similaire aux styles utilisés dans le populaire traitement de texte mot.

Les langages de script sont utilisés pour donner du dynamisme aux pages web (menus déroulants, animations). Le langage de script standard sur le World Wide Web est JavaScript. Le cœur du langage JavaScript est ECMAScript.

HTML, CSS, JavaScript sont les langages avec lesquels vous pouvez créer des sites Web arbitrairement complexes. Mais ce n'est qu'une disposition linguistique, alors que dans les navigateurs, les documents sont représentés comme un ensemble d'objets, dont l'ensemble de types est le Browser Object Model (BOM). Le modèle d'objet de navigateur est unique à chaque modèle, et il y a donc des problèmes lors de la création d'applications multi-navigateurs. Par conséquent, le consortium Web a proposé le modèle d'objet de document (DOM), qui est une manière standard de représenter des pages Web à l'aide d'un ensemble d'objets.

La syntaxe du HTML moderne est décrite à l'aide du XML du langage de balisage extensible. XML vous permettra de créer vos propres langages de balisage, similaires à HTML sous la forme d'une DTD. Il existe de nombreux langages de ce type : pour représenter des formules mathématiques et chimiques, des connaissances, etc.

Comme on peut le voir ci-dessus, toutes les technologies Web sont étroitement interconnectées. Comprendre ce fait facilitera la compréhension du but d'un mécanisme particulier utilisé pour créer des applications Web.

E-MAIL

Courrier électronique (e-mail, e-mail, du courrier électronique anglais) - technologie et services qu'elle fournit pour l'envoi et la réception messages électroniques(appelés "lettres" ou "e-mails") sur un réseau informatique distribué. La principale différence avec les autres systèmes de messagerie est la possibilité d'une livraison différée et un système développé d'interaction entre les serveurs de messagerie indépendants.

Le courrier électronique permet d'envoyer et de recevoir des messages, de répondre automatiquement aux lettres des correspondants en utilisant leurs adresses, d'envoyer des copies d'une lettre à plusieurs destinataires à la fois, de faire suivre la lettre reçue à une autre adresse, d'utiliser des noms logiques au lieu d'adresses (numériques ou noms de domaine), créez plusieurs sous-boîtes mail pour tous types de correspondances, intégrez des fichiers texte dans les courriers, utilisez le système "mail reflector" pour échanger avec un groupe de vos correspondants, etc. Pour envoyer un message électronique par e-mail, vous devez spécifier l'adresse de la boîte aux lettres. La boîte aux lettres d'un abonné à la messagerie électronique est une zone du disque dur d'un serveur de messagerie dédiée à un utilisateur.

Développement Technologies Internet a conduit à l'émergence de protocoles de messagerie modernes qui offrent de grandes possibilités de traitement des lettres, une variété de services et une facilité d'utilisation. Ainsi, par exemple, le protocole SMTP, qui fonctionne sur le principe client-serveur, est conçu pour envoyer des messages d'un ordinateur à un destinataire. Normalement, l'accès au serveur SMTP n'est pas protégé par un mot de passe, de sorte que n'importe quel serveur connu sur le réseau peut être utilisé pour envoyer du courrier. Contrairement aux serveurs d'envoi de courriers, l'accès aux serveurs de stockage des messages est protégé par un mot de passe. Par conséquent, vous devez utiliser un serveur ou un service qui a Compte. Ces serveurs utilisent les protocoles POP et IMAP, qui diffèrent dans la manière dont les messages sont stockés.

Conformément au protocole POP3, les messages arrivant à une adresse spécifique sont stockés sur le serveur jusqu'à ce qu'ils soient téléchargés sur l'ordinateur lors de la session suivante. Après avoir téléchargé les messages, vous pouvez vous déconnecter du réseau et commencer à lire le courrier. Ainsi, l'utilisation de la messagerie via le protocole POP3 est la plus rapide et la plus pratique à utiliser.

Le protocole IMAP est pratique pour les personnes qui utilisent une connexion permanente au réseau. Les messages reçus à l'adresse sont également stockés sur le serveur, mais contrairement à POP3, lors de la vérification du courrier, seuls les en-têtes de message seront téléchargés en premier. La lettre elle-même peut être lue après avoir sélectionné l'en-tête du message (elle sera téléchargée depuis le serveur). Il est clair qu'avec une connexion commutée, travailler avec la messagerie en utilisant ce protocole entraîne une perte de temps injustifiée.

Il existe plusieurs protocoles pour recevoir et transmettre du courrier entre des systèmes multi-utilisateurs.

Brève description certains d'entre eux:

1) SMTP (protocole de transfert de courrier simple) est un protocole réseau conçu pour la transmission de courrier électronique dans les réseaux TCP / IP, et la transmission doit nécessairement être initiée par le système émetteur lui-même.

MTA (Mail Transfer Agent) - agent de transfert de courrier - est le composant principal du système de transfert de courrier Internet, qui représente ce ordinateur réseau pour le système de messagerie du réseau. Habituellement, les utilisateurs ne travaillent pas avec le MTA, mais avec le programme MUA (Mail User Agent) - un client de messagerie. Schématiquement, le principe d'interaction est représenté sur la figure.

2) POP, POP2, POP3 (protocole postal)- trois protocoles non interchangeables assez simples conçus pour livrer le courrier à un utilisateur à partir d'un serveur de messagerie central, le supprimer de celui-ci et identifier un utilisateur par nom/mot de passe. POP inclut SMTP, qui est utilisé pour transférer le courrier provenant d'un utilisateur. Les messages électroniques peuvent être reçus sous forme d'en-têtes, sans recevoir la lettre entière.

Après l'établissement d'une connexion, le protocole POP3 passe par trois états successifs.

      1. Autorisation Le client passe par la procédure d'authentification
      2. La transaction client reçoit des informations sur l'état de la boîte aux lettres, accepte et supprime le courrier.
      3. La mise à jour du serveur supprime les e-mails sélectionnés et ferme la connexion.

3) IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (protocole d'accès aux messages Internet) - offre à l'utilisateur de riches possibilités de travailler avec des boîtes aux lettres situées sur un serveur central

o IMAP stocke le courrier sur le serveur dans des répertoires de fichiers et offre également au client la possibilité de rechercher des chaînes dans les messages électroniques sur le serveur lui-même.

o IMAP2 - utilisé dans de rares cas.

o IMAP3 - solution incompatible, non utilisée.

o IMAP2bis - L'extension IMAP2, permet aux serveurs d'analyser la structure MIME (Multipurpose Internet Mail Extensions) d'un message, est encore utilisée aujourd'hui.

o IMAP4 est un IMAP2bis repensé et amélioré qui peut être utilisé n'importe où.

o IMAP4rev1 - Étend IMAP avec un large éventail de fonctionnalités, y compris celles utilisées par DMSP (Distributed Mail System for Personal Computers).

4) ACAP (Application Configuration Access Protocol) - un protocole conçu pour fonctionner avec IMAP4 ; ajoute la possibilité d'un abonnement à la recherche et d'un abonnement aux babillards électroniques, boîtes aux lettres et est utilisé pour rechercher des carnets d'adresses.

5) DMSP (ou PCMAIL) est un protocole de réception/envoi de courrier dont la particularité est qu'un utilisateur peut avoir plus d'un poste de travail dans son utilisation. Le poste de travail contient des informations d'état sur le courrier, le répertoire par lequel l'échange a lieu, qui, lorsqu'il est connecté au serveur, est mis à jour à l'état actuel sur le serveur de messagerie.

6) MIME est une norme qui définit les mécanismes d'envoi de divers types d'informations par e-mail, y compris du texte dans des langues autres que l'anglais qui utilisent des codages de caractères autres que l'ASCII, et du contenu binaire 8 bits tel que des images, de la musique, des films et des programmes.

Travail indépendant.

Exécutez l'exemple donné dans le texte (polycopié) enregistrer dans propre dossier sur le bureau.

9.2. Travailler avec un professeur :

S'il y a des difficultés ou des actions erronées, contactez l'enseignant pour corriger les erreurs.

À la fin de la leçon, montrez à l'enseignant un rapport sur le travail effectué et recevez un crédit pour ce travail.

9.3. Contrôle du niveau initial et final des connaissances :

Tests informatiques .


Informations similaires.


URI (Uniform Resource Identifier) ​​​​est une chaîne compacte de caractères permettant d'identifier une ressource abstraite ou physique. Une ressource est tout objet appartenant à un espace. Le besoin d'un URI a été clair pour les concepteurs du WWW depuis la création du système. il était censé combiner en un seul environnement d'information des outils utilisant différentes manières identification des sources d'information. Une spécification a été développée qui incluait les appels vers FTP, Gopher, WAIS, Usenet, E-mail, Prospero, Telnet, X.500 et, bien sûr, HTTP (WWW). En conséquence, une spécification universelle a été développée qui vous permet d'élargir la liste des ressources adressables en raison de l'émergence de nouveaux schémas.

Lieu d'application de l'URI - liens hypertextes écrits dans des balises Et . Les objets graphiques intégrés sont également adressés par la spécification URI dans les balises Et . L'implémentation URI pour WWW est appelée URL (Uniform Resource Locator). Plus précisément, une URL est une implémentation d'un schéma d'URI mappé à un algorithme d'accès aux ressources par protocoles réseau. Il existe également un URN (Uniform Resource Name) qui mappe un URI à un espace de noms sur le Web.

L'apparence de l'URN est due au désir d'adresser des parties du message électronique MIME. Principes de construction d'une adresse WWW. Les URI sont basés sur les principes suivants :

· Extensibilité - Les nouveaux schémas d'adresses devraient facilement s'adapter à la syntaxe URI existante.

Complétude - dans la mesure du possible, tous les schémas existants doivent être décrits au moyen d'un URI.

· Lisibilité - l'adresse devait être facilement lisible par l'utilisateur, ce qui est généralement typique de la technologie WWW - les documents ainsi que les liens peuvent être développés dans un éditeur de texte ordinaire.

Avant d'examiner les différents schémas de représentation d'adresse, voici un exemple d'adresse URI simple :

http://polyn.net.kiae.su/polyn/index.html

Les deux-points sont précédés de l'identifiant du schéma d'adresse - "http". Ce nom est séparé par deux-points du reste de l'URI, qui est appelé "chemin". Dans ce cas, le chemin est composé de l'adresse de domaine de la machine sur laquelle le serveur HTTP est installé et du chemin depuis la racine de l'arborescence des serveurs jusqu'au fichier "index.html". En plus de ce qui précède dossier complet URI, il y en a une simplifiée. Il suppose qu'au moment de son utilisation, de nombreux paramètres d'adresse de ressource ont déjà été déterminés (protocole, adresse de machine sur le réseau, certains éléments de chemin). Dans de telles hypothèses, l'auteur de pages hypertextes ne peut indiquer que l'adresse relative de la ressource, c'est-à-dire une adresse relative à certaines ressources sous-jacentes.

L'URL (Uniform Resource Locator, Uniform Resource Locator) est un sous-ensemble de schémas d'URI qui identifie une ressource par la manière dont elle est accessible (par exemple, son "emplacement sur le réseau"), au lieu de l'identifier par le nom ou d'autres attributs de cette ressource. L'URL décrit explicitement comment accéder à l'objet.

Syntaxe: :, où:

schéma="http" | ftp | gopher | "mailto" | nouvelles | telnet | "fichier" | homme | infos | qu'est-ce que c'est | "LDAP" | "wais" | ...- nom du schéma

partie-spécifique-au-schéma– dépend du régime. Dans la partie spécifique au schéma, les valeurs hexadécimales peuvent être utilisées sous la forme : %5f. Les octets non imprimables doivent être codés : 00-1F, 7F, 80-FF.

Exemples d'URL :

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

URN (Uniform Resource Name) est un schéma d'URI privé "urn:" avec un sous-ensemble "espace de noms" qui doit être unique et inchangé même si la ressource n'existe plus ou n'est pas disponible.

On suppose que, par exemple, le navigateur sait où chercher cette ressource.

Syntaxe: urn : espace de noms : data1.data2,more-data, où namespace spécifie comment les données après le deuxième ":" sont utilisées.

Exemple d'URN :

Urne : ISBN : 0–395–36341–6

ISBN - classificateur thématique pour les éditeurs,

0-395-36341-6 - un numéro spécifique du sujet d'un livre ou d'un magazine

Dès réception d'un URN, le programme client accède à l'ISBN (le répertoire « classificateur de sujets pour les éditeurs » sur Internet). Et il reçoit une transcription du numéro de sujet « 0–395–36341–6 » (par exemple : « chimie quantique »). L'URN est relativement récent, n'est pas inclus dans les versions actuelles de HTML, et les services d'annuaire ne sont pas encore développés, de sorte que les URN ne sont pas aussi largement utilisés que les URL.

Schémas d'adressage des ressources Internet

Il existe 3 schémas d'adressage pour les ressources Internet. Le schéma précise son identifiant, l'adresse de la machine, le port TCP, le chemin dans le répertoire du serveur, les variables et leurs valeurs, le label.

Schéma HTTP. C'est le schéma de base du WWW. Le schéma spécifie son identifiant, l'adresse de la machine, le port TCP, le chemin dans le répertoire du serveur, les critères de recherche et l'étiquette.

Syntaxe: http://[ [:@][:][?]]

http- nom du schéma

utilisateur- Nom d'utilisateur

le mot de passe- mot de passe de l'utilisateur

héberger- nom d'hôte

Port- numéro de port

URL-chemin- le chemin d'accès au fichier et le fichier lui-même

mettre en doute (<имя–поля>=<значение>{&<имя–поля>=<значение>) - chaîne de requête

Par défaut, port=80.

Voici quelques exemples d'URI pour le schéma HTTP :

http://polyn.net.kiae.su/polyn/manifest.html

Il s'agit du type d'URI le plus couramment utilisé dans les documents WWW. Le nom du schéma (http) est suivi d'un chemin composé de l'adresse de domaine de la machine et de l'adresse complète du document HTML dans l'arborescence du serveur HTTP.

Une adresse IP peut également être utilisée comme adresse machine :

http://144.206.160.40/risque/risque.html

Si le serveur de protocole HTTP s'exécute sur un port TCP différent de 80, cela se reflète dans l'adresse :

http://144.206.130.137:8080/altai/index.html

http://polyn.net.kiae.su/altai/volume4.html#first

Schéma FTP. Ce schéma vous permet d'adresser des archives de fichiers FTP à partir de programmes clients du World Wide Web. Dans ce cas, le programme doit supporter le protocole FTP. Dans ce schéma, il est possible de spécifier non seulement le nom du schéma, l'adresse de l'archive FTP, mais également l'identifiant de l'utilisateur et même son mot de passe.

Syntaxe: ftp://[ [:@][:]

ftp- nom du schéma

utilisateur- Nom d'utilisateur

le mot de passe- mot de passe de l'utilisateur

héberger- nom d'hôte

Port- numéro de port

URL-chemin- le chemin d'accès au fichier et le fichier lui-même

Par défaut, port=21, utilisateur=anonyme, mot de passe=adresse e-mail.

Le plus souvent, ce schéma est utilisé pour accéder aux archives FTP publiques :

ftp://polyn.net.kiae.su/pub/0index.txt

Dans ce cas, un lien vers l'archive "polyn.net.kiae.su" est enregistré avec l'identifiant "anonyme" ou "ftp" (accès anonyme). S'il est nécessaire de spécifier l'ID utilisateur et le mot de passe, vous pouvez le faire avant l'adresse de la machine :

ftp://personne : [courriel protégé]/utilisateurs/local/pub

Dans ce cas, ces paramètres sont séparés de l'adresse machine par le symbole "@", et les uns des autres par deux-points.

Schéma TELNET. Ce schéma permet d'accéder à la ressource en mode terminal distant. Habituellement, le client appelle programme supplémentaire travailler sur le protocole telnet. Lors de l'utilisation de ce schéma, un ID utilisateur est requis et un mot de passe est autorisé.

Syntaxe: telnet://[ [:@][:]/

telnet- nom du schéma

utilisateur- Nom d'utilisateur

le mot de passe- mot de passe de l'utilisateur

héberger- nom d'hôte

Port- numéro de port

Par défaut, port=23.

Exemple : telnet://nom : [courriel protégé]

En réalité, l'accès est fait à des ressources publiques, et l'identifiant et le mot de passe sont publiquement connus, par exemple, ils peuvent être trouvés dans les bases de données Hytelnet.

telnet://invité : [courriel protégé]

Il ressort des exemples ci-dessus que la spécification des adresses de ressources URI est assez générale et vous permet d'identifier presque toutes les ressources sur Internet. Dans le même temps, le nombre de ressources peut être augmenté en créant de nouveaux régimes.

Service Internet

Le service WWW (World Wide Web) est destiné à l'échange d'informations hypertextes, construit selon le schéma "client-serveur". Le navigateur (Internet Explorer, Opera...) est un client multi-protocole et un interpréteur HTML. Et comme un interpréteur typique, le client exécute diverses fonctions en fonction des commandes (balises). Ces fonctions incluent non seulement le placement de texte sur l'écran, mais l'échange d'informations avec le serveur lors de l'analyse du texte HTML reçu, ce qui se produit le plus clairement lors de l'affichage d'images graphiques intégrées dans le texte.

Un serveur HTTP (Apache, IIS...) gère les requêtes client pour un fichier. Au départ, le service WWW reposait sur trois standards :

· HTML (HyperText Markup Language) – langage de balisage hypertexte des documents ;

URL (localisateur universel de ressources) – manière universelle ressources d'adressage dans le réseau ;

· HTTP (HyperText Transfer Protocol) – protocole d'échange d'informations hypertextes.

Schéma du serveur WWW

Un serveur WWW fait partie d'un réseau global ou intra-entreprise qui permet aux utilisateurs du réseau d'accéder à des documents hypertextes situés sur ce serveur. Pour interagir avec le serveur WWW, un utilisateur du réseau doit utiliser un logiciel spécialisé - un navigateur (du navigateur anglais) - un visualiseur.

Examinons de plus près le fonctionnement du serveur WWW :

1. L'utilisateur du réseau lance un navigateur dont les fonctions incluent :

établissement de connexion avec le serveur ;

obtenir le document requis;

affichage du document reçu ;

Répondre aux actions de l'utilisateur - accès à un nouveau document. Après le lancement, le navigateur, sur commande de l'utilisateur, ou établit automatiquement une connexion avec un serveur WWW donné et lui envoie une requête-réception d'un document donné.

2. Le serveur WWW recherche le document demandé et renvoie les résultats au navigateur.

3. Le navigateur, ayant reçu le document, l'affiche à l'utilisateur et attend sa réaction. Options possibles:

Saisie de l'adresse d'un nouveau document ;

Impression, recherche, autres opérations sur le document en cours ;

· activation (appui) de zones spéciales du document reçu, appelées liens (link) et associées à l'adresse du nouveau document. Dans les premier et troisième cas, une demande de nouveau document se produit.

Vous avez aimé l'article ? Partager avec des amis: