Le signe deux-points `:` est-il sûr pour une utilisation avec une URL conviviale?


109

Nous concevons un système d'URL qui spécifiera les sections d'application sous forme de mots séparés par des barres obliques. Plus précisément, c'est dans GWT, donc les parties pertinentes de l'URL seront dans le hachage (qui sera interprété par une couche de contrôleur côté client):

http://site/gwturl#section1/section2

Certaines sections peuvent nécessiter des attributs supplémentaires, que nous aimerions spécifier avec un :, afin que les parties de section de l'URL soient sans ambiguïté. Le code se diviserait d'abord sur /, puis sur :, comme ceci:

http://site/gwturl#user:45/comments

Bien sûr, nous le faisons pour la convivialité des URL, nous souhaitons donc nous assurer qu'aucun de ces caractères qui auront une signification particulière ne sera encodé par les navigateurs, ou tout autre système, et se retrouvera avec une URL comme ce:

http://site/gwturl#user%3A45/comments <--- BAD

Est-ce que l'utilisation des deux points de cette manière est sûre (ce que je veux dire ne sera pas automatiquement encodée) pour les navigateurs, les systèmes de signets, même le code Javascript ou Java?


Peut-être est-ce une bonne idée de spécifier (plus clairement) que vous utilisez les URL uniquement côté client? Étant donné que beaucoup de réponses (comme la mienne) semblent supposer que vous allez envoyer l'URL à un serveur en utilisant HTTP.
Veger

Modifié pour préciser que l'utilisation du fragment se produit du côté client.
Nicole

Je suis curieux: après 10 mois, ce schéma d'URL a-t-il fonctionné pour vous? J'envisage d'utiliser le même schéma.
Jonathan Swinney

1
@Jonathan Swinney, Malheureusement, j'ai quitté ce projet (et cette entreprise), même si les réponses ici m'ont convaincu que c'est la voie à suivre. Si je devais démarrer un nouveau projet, j'utiliserais ce schéma, mais je serais également sûr de l'utiliser #!pour indiquer que les pages sont avec état - voir googlewebmastercentral.blogspot.com/2009/10 / ... (Cette proposition a été respectée par de gros utilisateurs AJAX tels que Facebook)
Nicole

Je viens de découvrir que WhatsApp coupera une URL sur le premier deux-points, donc, par exemple, cela rendait une URL google maps inutile. Alors oui, il est important d'y échapper.
Petruza

Réponses:


84

J'ai récemment écrit un encodeur d'URL, donc c'est assez frais dans mon esprit.

http://site/gwturl#user:45/comments

Tous les caractères de la partie fragment ( user:45/comments) sont parfaitement légaux pour RFC 3986 URI .

Les parties pertinentes de l' ABNF :

fragment      = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

En dehors de ces restrictions, la partie fragment n'a pas de structure définie au-delà de celle que votre application lui donne. Le schéma, http, dit seulement que vous n'envoyez pas cette partie au serveur.


ÉDITER:

Oh!

Malgré mes affirmations sur la spécification URI, irreputable fournit la réponse correcte quand il souligne que la spécification HTML 4 restreint les noms / identificateurs d'élément .

Notez que les règles d'identifiant changent dans HTML 5 . Les restrictions d'URI s'appliqueront toujours (au moment de la rédaction de cet article, il y a des problèmes non résolus concernant l'utilisation des URI par HTML 5).


Je pense que vous êtes sur quelque chose, pouvez-vous l'expliquer un peu plus? Ne pas envoyer cela au serveur n'est pas un problème, car nous utilisons GWT. Je ne suis tout simplement pas sûr de comprendre la syntaxe spécifiée par la section que vous avez citée.
Nicole

Mais :c'est un gen-délim, pas un sous-délim.
bobince

1
Le point-virgule est légal pour un pchar, donc qu'il soit en sous-délimitation ou en délimitation gen n'est pas un problème
Veger

@bobince - :est dedans pchar, qui est dedans fragment, donc :est autorisé. @Renesis - Wikipedia a un article sur ABNF en.wikipedia.org/wiki/ABNF Vous regardez essentiellement une liste de caractères autorisés, où /signifie OU . Je n'ai pas fait de programmation GWT, donc je ne sais pas comment il utilise la partie fragment des URI.
McDowell

Une dernière question - avez-vous un aperçu de l'application réelle de cette spécification? Cela signifie-t-il que les navigateurs devraient / ignoreront (ignorer l'encodage) :le contenu du fragment?
Nicole

59

En plus de l'analyse de McDowell sur la norme URI, rappelez-vous également que le fragment doit être un nom d'ancre HTML valide. Selon http://www.w3.org/TR/html4/types.html#type-name

Les jetons ID et NOM doivent commencer par une lettre ([A-Za-z]) et peuvent être suivis de n'importe quel nombre de lettres, chiffres ([0-9]), tirets ("-"), traits de soulignement ("_") , deux points (":") et des points (".").

Alors vous avez de la chance. ":" est explicitement autorisé. Et personne ne devrait "%" - y échapper, non seulement parce que "%" est un caractère illégal, mais aussi parce que le fragment doit correspondre au nom de l'ancre char-par-caractère, donc aucun agent ne doit essayer de les altérer de quelque manière que ce soit.

Cependant, vous devez le tester. Les standards du Web ne sont pas strictement respectés, parfois les standards sont contradictoires. Par exemple, HTTP / 1.1 RFC 2616 n'autorise pas la chaîne de requête dans l'URL de la requête, tandis que HTML en construit une lors de la soumission d'un formulaire avec la méthode GET. Celui qui est mis en œuvre dans le monde réel l'emporte à la fin de la journée.


58

MediaWiki et d'autres moteurs wiki utilisent des deux-points dans leurs URL pour désigner les espaces de noms, sans apparemment aucun problème majeur.

par exemple http://en.wikipedia.org/wiki/Template:Bienvenue


31
Réponse la plus pertinente. Nous savons tous que ce qui est dans les spécifications n'a pas grand-chose à voir avec la réalité du développement Web. Vous n'obtiendrez pas une bien meilleure garantie de "sécurité" que "l'un des 10 meilleurs sites Web au monde le fait".
Steven Collins

1
@StevenCollins Pas plus pertinent que la réponse donnée 3 ans avant celle-ci qui dit exactement la même chose :)
Martin James

7

Je ne compterais pas dessus. Il sera probablement encodé en URL comme %3Apar de nombreux agents utilisateurs.


1
@arbales: Oui. Certains agents utilisateurs moins conformes laisseront les URL non conformes sans ornements.
Asaph

4

De URLEncoderjavadoc:

Pour plus d'informations sur l'encodage de formulaire HTML, consultez la spécification HTML .

Lors de l'encodage d'une chaîne, les règles suivantes s'appliquent:

  • Les caractères alphanumériques «a» à «z», «A» à «Z» et «0» à «9» restent les mêmes.
  • Les caractères spéciaux ".", "-", "*" et "_" restent les mêmes.
  • Le caractère espace "" est converti en signe plus "+".
  • Tous les autres caractères ne sont pas sûrs et sont d'abord convertis en un ou plusieurs octets à l'aide d'un schéma de codage. Ensuite, chaque octet est représenté par la chaîne de 3 caractères "% xy", où xy est la représentation hexadécimale à deux chiffres de l'octet. Le schéma de codage recommandé à utiliser est UTF-8. Cependant, pour des raisons de compatibilité, si un encodage n'est pas spécifié, alors l'encodage par défaut de la plateforme est utilisé.

Autrement dit, :n'est pas sûr.


3

Je ne vois pas Firefox ou IE8 encoder certaines des URL de Wikipédia qui incluent le caractère.


1
Opera garde également le point-virgule, mais compter sur un tel comportement n'est pas une bonne chose à faire
Veger

1
Renesis parle du fragment d'URL et non du chemin de l'URL.
Gumbo

Wikipédia était l'une de mes réflexions en écrivant cette question. Son utilisation des deux-points est-elle donc techniquement invalide / dangereuse? Je vois couramment (et) dans les URL de Wikipedia encodées, mais jamais les deux points, ce qui m'a laissé un peu confus.
Nicole

3
La Wayback Machine a un: dans beaucoup de ses liens - par exemple web.archive.org/web/20080822150704/http://stackoverflow.com
barrowc

2

Les deux points sont utilisés pour séparer le nom d'utilisateur et le mot de passe si un protocole nécessite une authentification.


0

Colon n'est pas sûr. Vois ici


Cette page ne explique pas pourquoi ils ne sont pas en sécurité. La RFC2396 référencée ne dit pas non plus qu'elle doit être échappée. De plus, le script de conversion fourni ne l'encode pas (dans Chrome 9 de toute façon).
Adam Lindberg

Adam, vous avez tort. Il énonce directement quoi et pourquoi.
ktamlyn

-5

Ce n'est pas un caractère sûr et est utilisé pour distinguer le port auquel vous vous connectez lorsqu'il se trouve juste après votre nom de domaine

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.