Author: fil@rezo.net
Date: 2008-05-24 13:12:27 +0200 (sam, 24 mai 2008)
New Revision: 11736
Log:
supprime var_ajaxcharset au profit d'un test de {{{ _SERVER[HTTP_X_REQUESTED_WITH] }}}, centralise (evidemment ce n'est pas si simple, en cas de 302 il faut tout de meme propager une variable car la variable dans SERVER n'est pas positionnee)
Author: fil@rezo.net
Date: 2008-05-24 13:12:27 +0200 (sam, 24 mai 2008)
New Revision: 11736
Log:
supprime var_ajaxcharset au profit d'un test de {{{ _SERVER[HTTP_X_REQUESTED_WITH] }}}, centralise (evidemment ce n'est pas si simple, en cas de 302 il faut tout de meme propager une variable car la variable dans SERVER n'est pas positionnee)
Bon bah voila, moi j'ai une extension qui est justement ce cas là. Alors je fais comment ?
Je vois vraiment pas l'intérêt de remplacer un code qui marchait bien par un autre incomplet et qui n'est meme pas un standard officiel.
Il semble egalement que les requetes ajax soumises via iframe (controunement de bugs dans IE) ne soient pas detectees par ce X_REQUESTED_WITH, et j'ai du reintroduire un test explicite sur var_ajax pour les formulaires cvt
Pas sur que l'upload de documents marche encore dans IE du coup.
Cédric
Le 30 mai 08 à 09:09, Committo,Ergo:sum a écrit :
Le 24 mai 08 à 13:12, fil@rezo.net a écrit :
Author: fil@rezo.net
Date: 2008-05-24 13:12:27 +0200 (sam, 24 mai 2008)
New Revision: 11736
Log:
supprime var_ajaxcharset au profit d'un test de
{{{ _SERVER[HTTP_X_REQUESTED_WITH] }}}, centralise (evidemment ce
n'est pas si simple, en cas de 302 il faut tout de meme propager une
variable car la variable dans SERVER n'est pas positionnee)
Bon bah voila, moi j'ai une extension qui est justement ce cas là.
Alors je fais comment ?
Je vois vraiment pas l'intérêt de remplacer un code qui marchait bien
par un autre incomplet et qui n'est meme pas un standard officiel.
supprime var_ajaxcharset au profit d'un test de {{{
_SERVER[HTTP_X_REQUESTED_WITH] }}}, centralise (evidemment ce n'est pas si
simple, en cas de 302 il faut tout de meme propager une variable car la
variable dans SERVER n'est pas positionnee)
Bon bah voila, moi j'ai une extension qui est justement ce cas là. Alors je
fais comment ?
Je l'ai ajoutée cette propagation ; ce qui était le plus aberrant
c'était de passer un charset
Je vois vraiment pas l'intérêt de remplacer un code qui marchait bien par un
autre incomplet et qui n'est meme pas un standard officiel.
l'objectif est de détecter l'ajax côté serveur plutôt que coté client
toutes les librairies ajax produisent cet entete sur les requetes
xmlhttprequest ; l'intérêt est de ne pas avoir à bidouiller l'URL.
mais en effet ce n'est pas si simple.
supprime var_ajaxcharset au profit d'un test de {{{
_SERVER[HTTP_X_REQUESTED_WITH] }}}, centralise (evidemment ce n'est pas si
simple, en cas de 302 il faut tout de meme propager une variable car la
variable dans SERVER n'est pas positionnee)
Bon bah voila, moi j'ai une extension qui est justement ce cas là. Alors je
fais comment ?
Je l'ai ajoutée cette propagation ;
où ça et comment ?
quand on fait des trucs comme ça ce serait bien de mettre dans le log au minimum des infos précises, et au mieux un Sed pour aide à la mise à jour.
ce qui était le plus aberrant
c'était de passer un charset
bah non, en fait on faisait coup double avec cette variable parce qu'on avait besoin aussi d'indiquer le charset, cf http://trac.rezo.net/trac/spip/changeset/7289
Actuellement dans mon extension, non seulement j'ai le cas de redirection qui foire,
mais en plus j'ai l'encodage qui part à l'ouest c'est abominable.
Si finalement il y a moyen de traiter le charset autrement, là aussi ce serait bien de dire comment.
mais pourquoi "passer" une info que, par définition, on connaît ?
Actuellement dans mon extension, non seulement j'ai le cas de redirection
qui foire, mais en plus j'ai l'encodage qui part à l'ouest c'est abominable.
il y a peut-être un bug ; la conversion de charset ne doit se faire
que sur xmlhttprequest, pas sur tous les appels ajax (iframe et
redirect)
Si finalement il y a moyen de traiter le charset autrement, là aussi ce
serait bien de dire comment.
Le truc c'est que le charset envoyé par des envois xmlhttprequest est
*toujours* de l'utf-8, même si le site est en iso-latin. Mais en effet
lors d'une redirection il faut propabalement propager l'info "ajax"
sans propager l'info "charset".
mon bug est à nouveau sur l'horreur de la fausse redirection de poster_forum_prive qui est en Post, redirection où tous les navigateurs violent les recommandations du RFC HTTP. Donc, c'est la bonne piste.
mais pourquoi "passer" une info que, par définition, on connaît ?
A l'époque c'était apparu indispensable, mais je ne sais plus pourquoi.
Si les logs sont bien écrits il doit sufire de les relire.
Actuellement dans mon extension, non seulement j'ai le cas de redirection
qui foire, mais en plus j'ai l'encodage qui part à l'ouest c'est abominable.
il y a peut-être un bug ; la conversion de charset ne doit se faire
que sur xmlhttprequest, pas sur tous les appels ajax (iframe et
redirect)
Ah, ça doit être ça en effet.
Si finalement il y a moyen de traiter le charset autrement, là aussi ce
serait bien de dire comment.
Le truc c'est que le charset envoyé par des envois xmlhttprequest est
*toujours* de l'utf-8,
Bon sang, mais c'est ce genre d'infos qu'il faut mettre dans les logs, avec un pointeur sur la doc!
Ca, ça se devine pas; tandis qu'une paraphrase des modifs du code ça sert à rien.