Comment voir quel nom de fichier mon navigateur lit lorsqu'il se trouve sur un site?
Il serait utile de savoir quel fichier un navigateur a trouvé à lire pour afficher la page d'accueil du domaine.
Je sais que le navigateur va à quelque chose comme google.com puis commence à rechercher des noms/types de fichiers par défaut tels que index.html puis peut-être index.htm et ainsi de suite dans une liste d'une douzaine d'autres fichiers .
Je suis curieux de savoir quel fichier mon navigateur a réellement commencé à afficher (un clic droit dans la fenêtre du navigateur et un clic sur "Enregistrer sous" ne donnent pas le nom du fichier). Ensuite, je me demande si un site commencerait à afficher un rendu plus rapide si le nom de fichier présent sur le domaine (par exemple, index.php) était l'une des tentatives de fichiers initiales recherchées par le navigateur par rapport à quelque chose de plus atypique (par exemple, placeholder.html).
Vos navigateurs ne chargent aucun fichier , il demande une ressource qui le serveur fournit ensuite à sa discrétion (développement détaillé ci-dessous).
Si vous tapez google.com dans la barre d’outils de votre navigateur, le navigateur ajoute d’abord un protocole, soit http:// ou https. Ensuite, le navigateur recherchera l'adresse IP appartenant à google.com, qui est 172.217.19.206. Votre navigateur établira alors un socket avec ce serveur sur le port approprié (80 pour http, 443 pour https).
Votre navigateur enverra alors la requête suivante au serveur:
GET / HTTP/1.1
Host: google.com
Le serveur Web décidera ensuite quoi faire. Cela peut impliquer beaucoup d'étapes.
Un serveur Web a généralement quelque chose appelé une racine de document pour tout domaine qu’il sert. Les fichiers que le serveur Web est autorisé à servir à l'utilisateur résident généralement à l'intérieur de la racine du document . Par exemple, la racine du document pour google.com pourrait résider à /var/www/domains/google.com/htdocs/.
Désormais, lorsque vous demandez une ressource, le serveur Web commence par l'inspecter, puis prend les mesures appropriées. Par exemple, si la ressource se termine par .php, le serveur Web peut décider de ne rien servir lui-même, mais appelle à la place l'interprète PHP et laisse l'exécution de l'interprète PHP. le fichier PHP approprié pour la ressource demandée, puis sert la sortie à l'utilisateur.
Prenons par exemple cette requête:
GET /article.php?id=123456 HTTP/1.1
Host: news.example.org
Dans ce cas, le serveur Web sur news.example.org est chargé de servir la ressource /article.php?id=123456. Ce qui se produit probablement, c’est que ce serveur Web lance l’interpréteur PHP. récupérez le fichier article.php à la racine du document, alimentez-le dans l'interpréteur PHP et attendez la sortie. Il enverra ensuite la sortie bck au navigateur qui l’a demandé. Dans ce cas, il s'agirait probablement d'un site provenant d'un blog avec un certain contenu chargé depuis une base de données (le contenu de l'article stocké avec l'identifiant 12345).
Mais d'autres choses peuvent arriver aussi.
Revenons à l'exemple original:
GET / HTTP/1.1
Host: google.com
Ce qui se passe avec n'importe quel serveur Web standard (Apache, Lighttpd, etc.), est plus ou moins le suivant:
- Recherchez un fichier nommé
index.html(dans la racine du document) et transmettez-le - Si cela n'existe pas, cherchez un fichier
index.htmet le servez - Si cela n’existe pas, cherchez un fichier
index.phpet lancez l’interprète PHP, puis envoyez le résultat. - Si cela n’existe pas, signalez une erreur
404 NOT FOUND
La priorité de l'extension est généralement configurable sur le côté du serveur Web. Le serveur peut ne servir aucun fichier index.xxx. Par exemple, si vous avez un serveur node.js en cours d'exécution, le serveur Web chargera le serveur node.js de fournir la ressource /, qui peut être tout ce que l'application JS exécutée est en cours d'exécution. sur le noeud décide qu'il soit.
tl: dr; Le navigateur ne cherche pas de fichier. Le navigateur demande une ressource , le serveur Web traite ensuite la demande et sert le contenu approprié pour la ressource demandée, ce qui pourrait être un fichier, mais pourrait également être la sortie d'un programme tiers.
En ce qui concerne la vitesse, cela dépend du serveur Web. Mais si vous souhaitez que votre serveur Web serve toujours le fichier asjkdjhfz9874jykdfndsk.html lorsque vous demandez /, vous devez généralement configurer le serveur Web pour rechercher un tel fichier en premier , le rendant aussi rapide que toute autre configuration.
Disclaimer Il ne s'agit pas d'une description complète du fonctionnement d'un serveur Web, ni d'une configuration spécifique. La plupart des serveurs Web fonctionnent de manière similaire, mais des sites tels que google.com exécutent probablement des tâches personnalisées adaptées à leurs besoins.
Votre navigateur proposera généralement des outils pour contrôler l'activité du réseau. À l'aide de Chrome, vous pouvez ouvrir les "Outils de développement" et inspecter les en-têtes. Voici ce que mon navigateur envoie à SE pour me permettre d’éditer cette réponse:
GET /posts/93567/edit HTTP/1.1
Host: webmasters.stackexchange.com
Il y en a quelques autres qui parlent au serveur de la mise en cache, de la langue à laquelle je m'attends, du navigateur que j'utilise et de l'endroit d'où je viens, mais ceux-ci ne sont pas intéressants ici. Le fait est que mon navigateur demande la ressource /posts/93567/edit. Mon navigateur n'aura jamais aucune idée du fichier utilisé par le serveur Web. SE s'exécute sur ASP.NET MVC 5 , ce qui signifie que le serveur Web (dans le cas d'un SE, un IIS) chargera probablement un fichier .asp approprié (pouvant être situé n'importe où), et permet au moteur d'exécution de l'évaluer pour le paramètre postId=93567. Le fichier ou les rouages internes sont jamais exposés au navigateur, car celui-ci n'a pas besoin de savoir (et parce qu'il est plus sûr de cacher ces informations pour celui qui exécute le serveur ).
La vue vous montrera également toutes les autres ressources (fichiers CSS, fichiers JS, images, etc.) demandées par votre navigateur pour restituer correctement le site. Mais avec eux, vous ne saurez que sur la ressource , que ce soit ou non des fichiers réellement dans le système de fichiers.
Le navigateur ne cherche pas de fichier. C'est juste demander un ressource. Le serveur décide alors du retour de cette ressource.
Au niveau le plus élémentaire, ce "fichier" est littéralement un fichier. Dans le cas de la page d'index par défaut d'un répertoire, la configuration du serveur déterminera les fichiers renvoyés. Certains serveurs sont configurés par défaut pour renvoyer index.html si le fichier existe, puis revenir à index.htm, etc. D'autres par défaut à default.html, etc. Ils continueront d'essayer jusqu'à la liste des paramètres par défaut. fichiers est épuisé et renverra alors une erreur 404.
Dans le cas où la réécriture du serveur est activée ou que des pages dynamiques sont en cours de construction, le contenu renvoyé n'est généralement pas un fichier. Il ressemble à un fichier car la sortie est (généralement) HTML comme le ferait un fichier .html. Mais en coulisse, des dizaines ou des centaines de fichiers créent ce contenu.
Je me demande comment je sais quel fichier est rendu. Je peux éventuellement le deviner avec précision sur un scénario suffisamment long en appelant simplement explicitement ce nom de fichier dans l'URL. www.xyz.com/index.html vous ne pouvez rien charger? Ensuite, essayez www.xyz.com/index.htm et ainsi de suite jusqu'à ce que le site soit rendu. Je cherche simplement un raccourci pour savoir quel fichier mon navigateur a chargé.
Je conviens avec John que ce que vous demandez en spécifiant une URL est une ressource (ou un meilleur mot, un objet) du serveur.
Vous ne saurez jamais à 100% avec certitude quel fichier de disque est lu lorsqu'une URL est demandée. Cela est particulièrement vrai si le serveur nécessite l’association d’un programme tiers afin de produire une sortie.
Un programme tiers typique est l'interprète PHP qui est quelque chose que Wordpress utilise pour diffuser du contenu. L'interpréteur peut traiter du code pouvant impliquer le chargement d'un nombre quelconque de fichiers à partir du disque du serveur afin de construire les données HTML qui sont ensuite transmises au navigateur de l'utilisateur.
De plus, une configuration spéciale peut être appliquée au serveur pour attribuer des URL spéciales aux ressources. Ceci (dans un environnement Apache) est connu sous le nom de réécriture d'URL, ce qui est très bien puisque c'est le début de la création d'URL conviviale.
Les utilisateurs ne connaîtront pas les noms de fichiers exacts des fichiers chargés et ne s'en soucieront pas (sauf s'il s'agit de pirates informatiques), car tout ce qui leur importe, c'est le contenu réel de la page.
Il est également possible que certains administrateurs de serveur décident de ne pas utiliser les noms de fichiers réels dans les URL pour des raisons de sécurité.
Je suis limité à 2 liens dans ma réponse ... pour parler de la façon dont les liens fonctionnent réellement, c'est un défi: -/Peut-être que je gagnerai quelques points et que je pourrais revenir et améliorer cette expiation bientôt.
Comme mentionné précédemment, les comportements et la réponse du site Web sont spécifiques au serveur utilisé et à son large éventail de paramètres. Je pourrais peut-être décrire le comportement "typique" d'un serveur LAMP (Linux Apache Mysql Php - Probablement le serveur Web le plus utilisé de nos jours)
Dans la configuration Apache d’exemple.com, vous aurez une directive DocumentRoot indiquant à Apache où rechercher un dossier correspondant à ce site, disons/www /
Vous pouvez avoir un fichier appelé .htaccess pouvant contenir des définitions spécifiques pour ce répertoire et tout son sous-répertoire.
Placer .htaccess dans/www/s’appliquera à l’ensemble du site (notez que, selon la convention Unix, un nom de fichier commençant par un point est un fichier caché)
Placer ce fichier ins/www/test/s’appliquera à tous les appels (GET POST PUT etc ...) commençant par http://exemple.com/test/ A GET http: // exemple.com/test/est en réalité
GET /test/ HTTP/1.1
Host: exemple.com
Mais il est plus facile d’écrire GET http: // exemple.com/test /
Apache recevra cet appel lorsqu'il écoutera sur le port 80. Lorsque vous verrez http://exemple.com:8080/ , cela signifie que vous forcez le port à l'état 8080.
http: // exemple.com/test/= http: // exemple.com: 80/test /
Apache recherchera un fichier .htaccess dans/www/et dans/www/test /
Il interprétera d'abord celui de/www/puis celui de/www/test/(bien sûr si le fichier existe)
Vous devez donc commencer par examiner ces fichiers car ils sont là pour donner des directives spécifiques qui ne sont pas le comportement par défaut.