| HTTP | GET |
|---|---|
| Demande | |
Syntaxe
| GET ressource protocole |
Paramètres
| Nom | Description | |
|---|---|---|
| ressource | Ce paramètre permet d'indiquer l'emplacement de la page Web sur le site. | |
| protocole | Ce paramètre permet d'indiquer le protocole que le client veut utiliser : | |
| Valeur | Description | |
| HTTP/1.0 | Cette valeur permet d'indiquer le protocole HTTP 1.0 (RFC 1945) | |
| HTTP/1.1 | Cette valeur permet d'indiquer le protocole HTTP 1.1 (RFC 2068, RFC 2616, RFC 7230, RFC 7237) | |
| ... | ... | |
Description
Cette méthode permet d'indiquer que l'envoi s'effectue en passant les champs du formulaires en paramètre URL.
Remarques
- La méthode GET demande le transfert d'une représentation actuellement sélectionnée pour la ressource cible. La méthode GET est le principal mécanisme de récupération des informations et le centre de presque toutes les optimisations de performances. Par conséquent, lorsque les gens parlent de récupérer des informations identifiables via HTTP, ils se réfèrent généralement à faire une requête GET.
- Il est tentant de considérer les identificateurs de ressources comme des chemins d'accès aux systèmes de fichiers à distances et les représentations comme une copie du contenu de ces fichiers. En fait, c'est le nombre de ressources mises en oeuvre. Cependant, il n'y a pas de telles limitations dans la pratique. L'interface HTTP pour une ressource est tout aussi susceptible d'être mise en oeuvre qu'une arborescence d'objets de contenu, une vue programmatique sur divers enregistrements de base de données ou une passerelle vers d'autres systèmes d'information. Même lorsque le mécanisme de cartographie d'URI est lié à un système de fichiers, un serveur d'origine peut être configuré pour exécuter les fichiers avec la requête en entrée et envoyer la sortie en tant que représentation plutôt que de transférer les fichiers directement. Quoi qu'il en soit, seul le serveur d'origine a besoin de savoir comment chacun de ses identifiants de ressource correspond à une mise en oeuvre et comment chacune de ses mises en oeuvre parvient à sélectionner et à envoyer une représentation actuelle de la ressource cible en réponse à GET.
- Un client peut modifier la sémantique de GET pour être une requête d'intervalle, en demandant le transfert de seulement une ou plusieurs parties de la représentation sélectionnée, en envoyant un champ d'entête Range: dans la requête.
- Une charge utile dans un message de requête GET n'a pas de sémantique définie; l'envoi d'un corps de charge utile sur une requête GET peut entraîner le rejet de la requête par certaines mises en oeuvres existantes.
- La réponse à une requête GET peut être mise en cache; une antémémoire peut l'utiliser pour satisfaire les requêtes GET et HEAD suivantes, sauf indication contraire par le champ d'entête Cache-Control:.
Exemple
Si vous souhaitez vous connecter en HTTP au port 80 sur le site www.gladir.com et demander le contenu :
GET / HTTP/1.0
HOST: www.gladir.com
On obtiendra le résultat suivant :
telnet www.gladir.com 80Trying 69.90.160.40...
Connected to www.gladir.com.
Escape character is '^]'.
GET / HTTP/1.0
HOST: www.gladir.com
HTTP/1.1 301 Moved Permanently
Date: Wed, 30 Aug 2017 17:03:51 GMT
Server: Apache
Location: https://www.gladir.com/
Content-Length: 231
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.gladir.com/">here</a>.</p>
</body></html>
Connection closed by foreign host.
Dernière mise à jour : Mercredi, le 30 août 2017