Je n'ai pas dit le contraire, puisque j'ai bien précisé que cela
demande une configuration particulière du serveur HTTP, c'est pas
Non, n'importe quoi. C'est le navigateur qui s'occupe de remettre
les & à leur place. Le serveur HTTP n'a rien à voir là-dedans.
Quant aux problèmes avec SPIP, c'est juste qu'il faut faire aussi
la conversion en sens inverse lors de la récupération du backend.
Non, n'importe quoi. C'est le navigateur qui s'occupe de remettre
les & à leur place. Le serveur HTTP n'a rien à voir là-dedans.
Exact, il y a erreur, c'est le serveur PHP qui doit savoir que &
est le séparateur des paramètres, mais ce pourrait tout aussi bien
être ; ou | ...
-Nicolas
Quant aux problèmes avec SPIP, c'est juste qu'il faut faire aussi
la conversion en sens inverse lors de la récupération du backend.
Hum... attends avant de commiter ça, je suis sur les charsets au même
endroit... presque fini 
-- Fil
Non, c'est le navigateur. Le "serveur PHP" n'a rien à voir là-dedans 
Hum... attends avant de commiter ça, je suis sur les charsets au même
endroit... presque fini
Oups, sorry, j'avais pas vu passer ton mail....
> Hum... attends avant de commiter ça, je suis sur les charsets au même
> endroit... presque finiOups, sorry, j'avais pas vu passer ton mail....
Pas de conflit, heureusement, c'est assez rubik's cube comme truc, j'avais
besoin de toute ma concentration
-- Fil
Pas de conflit, heureusement, c'est assez rubik's cube comme truc, j'avais
Ah zut, tu utilises filtrer_entites(), qui filtre tout, alors que tu ne veux
en fait filtrer que &... du coup ça ne marchera pas... une minute...
-- Fil
Exact, il y a erreur, c'est le serveur PHP qui doit savoir que
&Non, c'est le navigateur. Le "serveur PHP" n'a rien à voir là-dedans
J'ai raison, et je le sais, alors je persiste ... 
PHP s'est mis au goût du jour depuis longtemps d'ailleurs :
"A set of patches has been created to bring PHP's URL argument parser
into line with the W3C standard. However, deploying the PHP 4.0.5
release with these changes may very well break a large number of
installations.
To work around this problem, the two .ini directives
(arg_separator.input and arg_separator.output) which were created as
part of the fix, will both default to the current behavior."
cf http://www.zend.com/zend/week/week32.php#Heading6
-Nicolas
"A set of patches has been created to bring PHP's URL argument parser
into line with the W3C standard. However, deploying the PHP 4.0.5
release with these changes may very well break a large number of
installations.
To work around this problem, the two .ini directives
Et quel est ce "problème" ?
Et quel est ce "problème" ?
Quelques lectures :
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
-Nicolas
Quelques lectures :
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
Error Explanations for The W3C Markup Validation Service
Ce qui dit exactement :
"A reference to a URI that uses & as a separator between parameters,
such as "http://example.org/prog?x=1&y=2"\.
To solve this problem, simply replace all the &'s in attribute values
with & (user agents will convert them back before following the
links.)"
On parle bien de "user agents" et pas de serveurs HTTP.
De toute façon, comment expliques-tu que SPIP ait eu des & dans les
URLs syndiquées depuis belle lurette (on ne décodait pas les entités
XML) sans qu'il y ait eu le moindre bug rapporté ?
Ce qui dit exactement :
"[...]"
On parle bien de "user agents" et pas de serveurs HTTP.
Oui, mais pas "exactement", puisque tu omets la suite :
"We recommend that HTTP server implementors, and in particular, CGI
implementors support the use of ";" in place of "&" to save authors
the trouble of escaping "&" characters in this manner."
De toute façon, comment expliques-tu que SPIP ait eu des & dans
les URLs syndiquées depuis belle lurette (on ne décodait pas les
entités XML) sans qu'il y ait eu le moindre bug rapporté ?
Je n'ai jamais dit qu'il aurait dû y avoir des bugs !
-Nicolas