web-dev-qa-db-fra.com

Les deux points `:` sont-ils sûrs pour l'utilisation d'URL amicale?

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

http://site/gwturl#section1/section2

Certaines sections peuvent nécessiter des attributs supplémentaires, que nous aimerions spécifier avec un :, de sorte que les sections de l’URL ne soient pas ambiguës. Le code serait divisé en premier sur /, puis sur :, comme ça:

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

Bien sûr, nous le faisons pour plus d'url, nous aimerions donc nous assurer qu'aucun de ces caractères ayant une signification particulière ne sera encodé par l'URL par les navigateurs, ou par tout autre système, et aboutira à une URL comme cette:

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

Utilise le côlon de cette façon sûr (par ce que je veux dire ne sera pas automatiquement encodé) pour les navigateurs, les systèmes de bookmarking, même Javascript ou Java?

urlgwtspecial-charactersfriendly-url
100
Nicole

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

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

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

Les parties pertinentes du 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ée n'a pas de structure définie en dehors de celle que votre application lui donne. Le schéma, http, indique seulement que vous n'envoyez pas cette partie au serveur.

MODIFIER:

D'oh!

En dépit de mes affirmations sur la spécification URI, irrévocable fournit la réponse correcte lorsque il fait remarquer que la spécification HTML 4 restreint les noms/identificateurs d'éléments .

Notez que les règles d'identifiant sont changeant en HTML 5 . Les restrictions d'URI continueront à s'appliquer (au moment de la rédaction de cet article, l'utilisation d'URIs par HTML 5 n'est pas résolue).

74
McDowell

Outre l'analyse de McDowell sur la norme URI, rappelez-vous également que le fragment doit être un nom d'ancrage 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 par un nombre quelconque de lettres, chiffres ([0-9]), traits d'union ("-"), traits de soulignement ("_") , deux points (":") et périodes (".").

Donc 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 fragment correspond beaucoup au nom de l'ancre, caractère par caractère, de sorte qu'aucun agent ne devrait tenter de les tempérer.

Cependant, vous devez le tester. Les normes Web ne sont pas strictement suivies, parfois les normes sont en conflit. 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 gagne à la fin de la journée.

56
irreputable

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

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

54
Paul Wray

Je ne compterais pas dessus. L'URL sera probablement encodée en tant que %3A par de nombreux agents utilisateurs.

7
Asaph

De URLEncoder javadoc:

Pour plus d'informations sur le codage de formulaire HTML, consultez HTML spécification .

Lors du codage 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 d'espace "" est converti en un signe plus "+".
  • Tous les autres caractères sont dangereux 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é est UTF-8. Toutefois, pour des raisons de compatibilité, si aucun codage n'est spécifié, le codage par défaut de la plate-forme est utilisé.

C'est, : n'est pas sans danger.

4
axtavt

Je ne vois pas Firefox ou IE8 encoder une partie de la Wikipedia RL qui inclut le caractère.

3
kprobst

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

3
JP Silvashy

Deux points ne sont pas en sécurité. voir ici

0
Bob