Est-il prudent de toujours ignorer la barre oblique de fin de chaîne lors de l'ajout d'une chaîne de requête ?
C'est-à-dire, est-ce que je peux utiliser
http://example.com?querystringau lieu de :
http://example.com/?querystring? Tous les hébergeurs que j'ai utilisés supportent cette méthode, mais peut-on supposer que tous les environnements de serveur la supportent ? Est-elle standard ?
En ce qui concerne les spécifications modernes, oui il est permis de ne pas utiliser la barre oblique. contrairement à ce que le réponse acceptée prétend ici.
Bien que la réponse acceptée cite correctement la RFC 1738 (publiée il y a plus de 20 ans !), elle affirme à tort que la RFC 2396 (publiée en 1998) exige le slash, et néglige le fait que les deux de ces spécifications ont été à leur tour obsolètes par RFC 3986 publié en 2005 (encore plusieurs années avant la rédaction de la réponse acceptée) et plus récemment par la Norme URL du WhatWG qui permettent tous deux d'omettre la barre oblique.
Examinons successivement chacune de ces spécifications, de la plus ancienne à la plus récente :
Implicitement, la barre oblique doit être incluse par précisant qu'il mai être omis si l'URL ne contient ni chemin ni chaîne de requête (appelé searchpart ici). Les caractères gras ci-dessous sont les miens :
Une URL HTTP prend la forme :
http://<host>:<port>/<path>?<searchpart>où
<host>y<port>sont tels que décrits dans Section 3.1 . Si :<port>est omis, le port a la valeur 80 par défaut. Aucun nom d'utilisateur ou mot de passe n'est mot de passe n'est autorisé.<path>est un sélecteur HTTP, et<searchpart>est une requête de requête. Le site<path>est facultatif, tout comme l'est le<searchpart>et son précédent " ?". Si aucun des deux<path>ni<searchpart>est présent, le "/" peut également être omis.
Ici, il est acceptable d'omettre la barre oblique. Cette RFC légalise certaines syntaxes d'URL bizarres qui n'ont pas de double barre oblique après le schéma, mais si nous les ignorons (ce sont celles qui ont un caractère opaque_part dans la spécification BNF ) et s'en tiennent aux URL qui contiennent un hôte, alors nous constatons qu'un absoluteURI est défini comme suit...
absoluteURI = scheme ":" ( hier_part | opaque_part )
et qu'un hier_part ressemble à ça :
hier_part = ( net_path | abs_path ) [ "?" query ]
et qu'un net_path ressemble à ça :
net_path = "//" authority [ abs_path ]
où un abs_path est à son tour défini pour commencer par une barre oblique. Notez que le abs_path es en option dans la grammaire ci-dessus - cela signifie qu'une URL de la forme scheme://authority?query est tout à fait légal.
La motivation de ce changement est évoquée dans l'annexe. G.2. Modifications du RFC 1738 et du RFC 1808 :
Le point d'interrogation " ? " a été supprimé de l'ensemble des caractères autorisés pour l'info utilisateur i. autorisés pour les informations sur l'utilisateur dans le composant d'autorité, car les tests ont montré que de nombreuses applications le considèrent comme réservé pour séparer le du reste de l'URI.
En d'autres termes, dans le monde réel, le code partait du principe que le premier point d'interrogation d'une URL, où qu'il soit, marquait le début d'une chaîne d'interrogation.
Là encore, il est permis d'omettre la barre oblique. La spécification exprime cela en disant qu'un "chemin" est requis dans chaque URI qui contient une autorité (hôte), et ce chemin doit o bien commencent par une barre oblique o ne comporte aucun caractère :
La syntaxe générique des URI consiste en une séquence hiérarchique de composants appelés schéma, autorité, chemin, requête et fragment. fragment.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-emptyLes composants scheme et path sont obligatoires, bien que le path puisse être vide (aucun caractère). Lorsque l'autorité est présente, le chemin doit être vide ou commencer par une barre oblique ("/").
Pour être complet, notons que path-abempty est ensuite défini ainsi :
path-abempty = *( "/" segment )
Cela permet en effet qu'il ne contienne aucun caractère.
Une fois de plus, l'omission de la barre oblique est acceptable, bien que cette fois-ci, nous n'ayons pas de BNF à examiner, mais plutôt besoin de lire beaucoup de prose.
Section 4.3 nous dit :
Un site chaîne absolute-URL doit être l'un des suivants
- a Chaîne de schéma URL qui est un ASCII insensible à la casse pour un régime spécial et non un ASCII insensible à la casse match pour "
file", suivi de ":" et un chaîne scheme-relative-special-URL- a Chaîne de schéma URL c'est-à-dire no un ASCII insensible à la casse pour un régime spécial suivi de " :" et d'un chaîne relative-URL
- a Chaîne de schéma URL qui est un ASCII insensible à la casse pour "file", suivi de " :" et d'un mot de passe chaîne scheme-relative-file-URL
éventuellement suivi de " ?" et d'une chaîne de requête URL.
Puisque HTTP et HTTPS sont régimes spéciaux En effet, toute URL HTTP ou HTTPS doit satisfaire à la première de ces trois options, c'est-à-dire à la deuxième, http: o https: suivi d'un chaîne scheme-relative-special-URL qui :
doit être "
//", suivi d'un chaîne hôte valide éventuellement suivi de ":" et un Chaîne de l'URL-port éventuellement suivi d'un chaîne path-absolute-URL .
A chaîne path-absolute-URL doit commencer par une barre oblique, mais elle est explicitement facultative dans la définition d'une chaîne URL absolue ci-dessus ; ainsi, il est permis de passer directement de l'hôte à la chaîne " ? " et la chaîne de requête, et donc des URL comme http://example.com?query sont légales.
Bien sûr, rien de tout cela ne garantit que chaque serveur Web ou bibliothèque HTTP acceptera ces URL, ni qu'ils les traiteront comme sémantiquement équivalentes à une URL contenant la barre oblique. Mais en ce qui concerne spec va, sauter la barre oblique est tout à fait légal.
Non. Il n'est pas correct de sauter la barre oblique. Il mai fonctionne avec les navigateurs modernes : cela ne signifie pas pour autant qu'il soit correct.
Ver RFC1738 - URL y RFC2396 - URI .
Le format selon RFC1738 (j'ai exclu le format du schéma ici) :
//user>:<password>@<host:<port>/<url-path>
Et il poursuit en notant que :
...le "/" entre l'hôte (ou le port) et le chemin d'accès à l'URL ne fait PAS partie du chemin d'accès à l'URL.
Dans ce cas, le " ?" fait partie du chemin d'accès à l'url qui
...dépend du schéma utilisé, ainsi que de la manière dont il est interprété.
Notez également que, par spécification, il est parfaitement valable de omettre "/url-path" -- notez que le "/" a été explicitement inclus dans ce cas.
Ainsi, "foo.com?bar" n'est pas valide car il n'y a pas de "/" devant le chemin d'accès.
J'ajoute à la réponse acceptée quelques informations supplémentaires que j'ai trouvées après avoir fait des recherches sur ce problème :
https://www.rfc-editor.org/rfc/rfc2396
Le composant d'autorité est précédé d'une double barre oblique "//" et se termine par la barre oblique suivante "/", le point d'interrogation " ?" ou la fin de l'URI. Dans le composant d'autorité, les caractères " ;", " :", "@", " ?" et "/" sont réservés.
Sur la base de cette déclaration, le point d'interrogation devrait indiquer la fin de la composante d'autorité, avec ou sans la barre oblique.
https://www.rfc-editor.org/rfc/rfc1738 (tags remplacés)
Le {path} est facultatif, tout comme le {searchpart} et son " ?" précédent. Si ni {chemin} ni {partie de recherche} ne sont présents, le "/" peut également être omis.
Toutefois, cette déclaration indique que la barre oblique de fin ne peut être omise que si le chemin et la partie de recherche ne sont pas prédéfinis.
Dans le monde réel, j'ai déjà été en mesure d'omettre une barre oblique de fin avant une valeur de requête, mais j'ai récemment trouvé une situation où cela ne fonctionne pas. Si vous avez une requête telle que celle-ci http://my.domain.com?do=something et que vous affichez une page html dans Internet Explorer, le lien est le suivant Correction de par IE. Si vous cliquez ensuite sur Fichier, Envoyer, Page par e-mail..., le lien est ajouté à l'e-mail avec un format invalide. Les problèmes varient en fonction du contenu de la valeur de la requête, mais nous avons réussi à créer des URL invalides.
En résumé, il devrait fonctionne, mais tombe en panne dans les cas limites.
Il est no On peut supposer que c'est le cas. Les serveurs Web et les applications Web autonomes inspectent généralement l'URL fournie dans la demande, mais il n'y a aucune garantie qu'ils traiteront les données de l /abc égal à /abc/ . Les serveurs web et les applications web autonomes peuvent faire tout ce qu'ils aiment avec les informations glanées dans l'URL, et ce ne sera pas nécessairement ce que vous attendez. Vous devrez vous renseigner sur la convention applicable à l'URL en question.
Notez, bien sûr, que la plupart des serveurs web et des cadres d'applications web s'efforcent d'accepter toutes sortes d'entrées et de les traiter de manière appropriée. Par conséquent, dans la plupart des cas, le serveur web ou l'application web autonome traitera /abc égal à /abc/ . Mais n'oubliez pas, puisque le serveur peut faire ce qu'il veut avec le chemin, qu'il s'agit simplement d'une observation générique avec de nombreuses exceptions potentielles.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
