Retourner aux forums || Retourner au forum LinuxFr.idees
LinuxFr.idees : La virgule derrière une URL - le retour
Posté par M. A. () le 14 septembre 2004Je reviens à la charge après un WE à potasser la doc Templeet ;-)
Une méthode simple qui je pense peut éviter la plupart du temps ce pb :
- si une URL se termine par une virgule => tester la validité de l'URL sans, si OK stocker l'URL sans la virgule finale, sinon on ne touche à rien.
Qu'en pensez-vous ?
> Lire le message (4 commentaires, moyenne: 2).
Read the RFC, Luke
La virgule ne fait pas partie des caractères autorisés dans un URL, donc de toute façon, il faut au moins la remplacer par un %2c dans l'URL.
(bon, maintenant, si ça parle de Templeet et des subtilités de son langage, ma réponse doit être à côté de la plaque... le message n'avait être plus clair)
-
[^]Re: Read the RFC, Luke
Posté par M. A. () le 14/09/2004 à 08:59. (lien). Évalué à 1.En fait, c'est suite à ce commentaire : http://linuxfr.org/comments/471452.html#471452(...)
le message n'avait être plus clair : c'est vrai.
La virgule ne fait pas partie des caractères autorisés dans un URL
Je demande à voir (quelle RFC, quel chapitre ?)-
[^]Re: Read the RFC, Luke
Posté par pas_moi () le 14/09/2004 à 09:06. (lien). Évalué à 3.Au temps pour moi, après revérification dans http://www.faqs.org/rfcs/rfc1738.html(...) il s'avère que la virgule fait partie de "uchar", caractères autorisés dans le chemin d'un URL HTTP...
-
Bof
> Qu'en pensez-vous ?
Que je mettrais alors quelques centaines/milliers de liens pointant sur un site sensible en .mil dans un commentaire...
Que je mettrais alors un lien type "truc.php?file=/etc/passwd&pipo=,"...
etc.
Un serveur web n'a pas à faire des requêtes pour tester ce genre de chose.
(de toute façon, à la place, je poste un seul lien vers ce .mil sur Slashdot)
Revenir en haut de page || Retourner aux forums || Retourner au forum LinuxFr.idees



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.