Point-virgule comme séparateur de requête d'URL

Question

Bien qu'il soit fortement recommandé ( Source W3C via Wikipedia ) pour que les serveurs web prennent en charge le point-virgule comme séparateur d'éléments de requête d'URL (en plus de l'esperluette), elle ne semble pas être généralement suivie.

Par exemple, comparez

         http://www.google.com/search?q=nemo & oe=utf-8

         http://www.google.com/search?q=nemo ; oe=utf-8

résultats. (Dans ce dernier cas, le point-virgule est, ou l'était au moment de la rédaction de ce texte traité comme une chaîne de caractères ordinaire, comme si l'url était : http://www.google.com/search?q=nemo %3B oe=utf-8 )

Bien que la première bibliothèque d'analyse d'URL que j'ai essayée se comporte bien :

>>> from urlparse import urlparse, query_qs
>>> url = 'http://www.google.com/search?q=nemo;oe=utf-8'
>>> parse_qs(urlparse(url).query)
{'q': ['nemo'], 'oe': ['utf-8']}

Quel est le statut actuel de l'acceptation du point-virgule comme séparateur, et quels sont les problèmes potentiels ou les remarques intéressantes ? (tant du point de vue du serveur que du client)

Answer 1

Le site Recommandation du W3C de 1999 est obsolète. Le statut actuel, selon le Recommandation du W3C de 2014 c'est que le point-virgule est maintenant illégal comme séparateur de paramètres :

Pour décoder les charges utiles codées en application/x-www-form-urlencode, l'algorithme suivant doit être utilisé. [...] La sortie de cet algorithme est une liste triée de paires nom-valeur. [...]

1. Que les chaînes soient le résultat de la division stricte de la charge utile de la chaîne sur les caractères AMPERSAND U+0026 (&).

En d'autres termes, ?foo=bar;baz signifie que le paramètre foo aura la valeur bar;baz ; considérant que ?foo=bar;baz=sna devrait donner lieu à foo être bar;baz=sna (bien que techniquement illégale puisque la deuxième = doit être échappé en %3D ).

Answer 2

Tant que votre serveur HTTP et votre application côté serveur acceptent les points-virgules comme séparateurs, tout devrait bien se passer. Je ne vois pas d'inconvénients. Comme vous l'avez dit, le La spécification du W3C est de votre côté :

Nous recommandons aux responsables de la mise en œuvre des serveurs HTTP, et en particulier aux responsables de la mise en œuvre des CGI, de prendre en charge l'utilisation de " ;" à la place de "&" pour éviter aux auteurs d'avoir à échapper les caractères "&" de cette manière.

Answer 3

Je suis d'accord avec Bob Aman. La spécification du W3C est conçue pour faciliter l'utilisation d'hyperliens d'ancrage avec des URL qui ressemblent à des requêtes GET de formulaire (par exemple, " http://www.host.com/?x=1&y=2 "). Dans ce contexte, l'esperluette entre en conflit avec le système des références aux entités de caractères, qui commencent toutes par une esperluette (par exemple, ""e ;"). Le W3C recommande donc aux serveurs Web d'autoriser l'utilisation d'un point-virgule comme séparateur de champ à la place de l'esperluette, afin de faciliter l'écriture de ces URL. Mais cette solution exige que les rédacteurs se souviennent que l'esperluette doit être remplacée par quelque chose, et que le " ;" est un délimiteur de champ tout aussi valable, même si les navigateurs Web utilisent universellement l'esperluette. C'est sans doute plus difficile que de se souvenir de remplacer l'esperluette par un "&" dans ces liens, comme ils le feraient ailleurs dans le document.

Pour aggraver les choses, jusqu'à ce que tous les serveurs web autorisent les points-virgules comme délimiteurs de champ, les rédacteurs d'URL ne peuvent utiliser ce raccourci que pour certains hôtes, et doivent utiliser "&" pour d'autres. Ils devront également modifier leur code ultérieurement si un hôte donné n'autorise plus les points-virgules comme délimiteurs de champ. C'est certainement plus difficile que d'utiliser simplement "&", qui fonctionnera pour tous les serveurs à tout moment. En outre, cela n'incite pas les serveurs web à autoriser les points-virgules comme séparateurs de champ. À quoi bon, alors que tout le monde remplace déjà l'esperluette par "&" au lieu de " ;"?

Answer 4

En bref, le HTML est un grand fouillis (en raison de son indulgence), et l'utilisation des points-virgules permet de le simplifier grandement. J'estime que lorsque je prends en compte les complications que j'ai trouvées, l'utilisation des esperluettes comme séparateur rend l'ensemble du processus trois fois plus compliqué que l'utilisation des points-virgules comme séparateurs !

Je suis un programmeur .NET et, à ma connaissance, .NET ne no J'ai donc écrit mes propres méthodes d'analyse et de traitement parce que je voyais une énorme valeur dans l'utilisation des points-virgules plutôt que dans le système déjà problématique des esperluettes comme séparateurs. Malheureusement, des personnes très respectables (comme @Bob Aman dans une autre réponse) ne voient pas l'intérêt de l'utilisation du point-virgule qui est de loin supérieure et tellement plus simple que l'utilisation des esperluettes. Je partage donc maintenant quelques points pour peut-être persuader d'autres développeurs respectables qui ne reconnaissent pas encore la valeur de l'utilisation des points-virgules à la place :

L'utilisation d'une chaîne de requête comme '?a=1&b=2' dans une page HTML est impropre (sans codage HTML préalable), mais la plupart du temps, elle fonctionne. Cela n'est toutefois dû qu'à la tolérance de la plupart des navigateurs, et cette tolérance peut conduire à des bogues difficiles à trouver lorsque, par exemple, la valeur de la paire clé-valeur est affichée dans l'URL d'une page HTML sans codage approprié (directement sous la forme '?a=1&b=2' dans la source HTML). Une chaîne de requête comme "?who=me+&+you" est également problématique.

Nous, les gens, pouvons avoir préjugés et pouvons être en désaccord sur nos partis pris toute la journée, il est donc très important de reconnaître nos partis pris. Par exemple, je suis d'accord pour dire que je trouve que les séparations avec " ;" sont plus "propres". Je reconnais que mon opinion "plus propre" est purement un préjugé. Et un autre développeur peut avoir un parti pris tout aussi opposé et tout aussi valable. Donc mon parti pris sur ce point n'est pas plus correct que le parti pris opposé.

Mais le soutien impartial du point-virgule, qui facilite la vie de tous à long terme, ne peut être contesté correctement si l'on tient compte de l'ensemble du tableau. En résumé, l'utilisation du point-virgule simplifie effectivement la vie des personnes suivantes tout le monde à une exception près : un petit obstacle pour s'habituer à quelque chose de nouveau. C'est tout. Il est toujours plus difficile de faire changer quelque chose. Mais la difficulté de changer n'est rien en comparaison de la difficulté de continuer à utiliser &.

L'utilisation de ; comme séparateur de chaîne de requête simplifie grandement les choses. Les séparateurs de type esperluette sont plus de deux fois plus difficiles. pour coder correctement que si des points-virgules étaient utilisés. (Je pense) que la plupart des implémentations ne sont pas codées correctement, donc la plupart des implémentations ne sont pas deux fois plus compliquées. Mais la recherche et la correction des bogues entraînent une perte de productivité. Ici, j'indique deux étapes de codage distinctes nécessaires pour coder correctement une QueryString lorsque & est le séparateur :

• Étape 1 : L'URL code les clés et les valeurs de la chaîne de recherche.
• Étape 2 : Concaténer les clés et les valeurs comme 'a=1&b=2' après qu'elles aient été codées par URL à l'étape 1.
• Etape 3 : Ensuite, le HTML encode la QueryString entière dans la source HTML de la page.

Ainsi, un encodage spécial doit être effectué deux fois pour un encodage correct (sans bogue) des URL, et non seulement cela, mais les encodages sont deux types d'encodage distincts et différents. Le premier est un encodage URL et le second est un encodage HTML (pour le code source HTML). Si l'un d'entre eux est incorrect, alors je peux vous trouver un bug. Mais l'étape 3 est différente pour XML. Pour XML, l'encodage des entités de caractères XML est nécessaire à la place (ce qui est presque identique). Ce que je veux dire, c'est que le dernier encodage dépend du contexte de l'URL, que ce soit dans une page Web HTML ou dans une documentation XML.

Maintenant, avec les séparateurs de point-virgule, beaucoup plus simples, le processus est tel que l'on peut s'y attendre :

• 1 : Les URL codent les clés et les valeurs,
• 2 : concaténer les valeurs ensemble. (Sans codage pour l'étape 3).

Je pense que la plupart des développeurs web sautent l'étape 3 parce que les navigateurs sont si indulgents. Mais cela conduit à des bugs et à plus de complications lors de la recherche de ces bugs ou à des utilisateurs qui ne peuvent pas faire certaines choses si ces bugs ne sont pas présents, ou à la rédaction de rapports de bugs, etc.

Une autre complication dans l'utilisation réelle est l'écriture de balises de documentation XML dans mon code source en C# et VB.NET. Puisque & doit être encodé, c'est un véritable frein, littéralement, à ma productivité. Cette étape supplémentaire rend également la lecture du code source plus difficile. Ce déficit de lisibilité s'applique donc non seulement au HTML et au XML, mais aussi à d'autres applications comme le code C# et VB.NET, car leur documentation utilise la documentation XML. La complication de l'encodage de l'étape 3 se propage donc à d'autres applications également.

En résumé, l'utilisation du ; comme séparateur est simple parce que le processus (correct) lors de l'utilisation du point-virgule est celui que l'on attend normalement : une seule étape de codage doit avoir lieu.

Peut-être que ce n'était pas trop confus. Mais toute la confusion ou la difficulté est due à l'utilisation d'un caractère de séparation qui devrait être codé en HTML. Ainsi, '&' est le coupable. Le point-virgule élimine toute cette complication.

(Je tiens à préciser que mon processus en 3 étapes contre 2 étapes ci-dessus est généralement combien d'étapes il faudrait pour le plus applications. Cependant, pour un code totalement robuste, les 3 étapes sont nécessaires, quel que soit le séparateur utilisé. Mais d'après mon expérience, le plus Les implémentations sont bâclées et peu robustes. Ainsi, l'utilisation du point-virgule comme séparateur de chaîne de requête faciliterait la vie d'un plus grand nombre de personnes avec moins de bogues de site web et d'interopérabilité, si tout le monde adoptait le point-virgule comme valeur par défaut au lieu de l'esperluette).