J'ai plusieurs sites qui fonctionnent bien depuis des années.
Depuis quelques temps, je détecte des erreur bizarres apparemment dues
au fait que
certaines pages appelées par un <FORM METHOD="POST" reçoivent en fait la
requête en mode GET.
La variable CGI REQUEST_METHOD contient en effet GET au lieu de POST,
et le scope
de variable qui correspondent au FORM est vide :-(
Ça arrive peut-être une fois sur 200, le reste du temps, tout est normal.
J'ai un collègue qui a détecté exactement le même problème, lui est sous
Linux avec ColdFusion 7,
moi sous Windows avec ColdFusion 5, donc le problème ne semble pas se
situer au niveau du serveur.
Par contre, nous avons remarqué que le problème arrive tj avec des
utilisateurs qui ont IE7.
D'où ma question : y aurait-il une problème connu avec le POST/GET sous
IE7, et si oui, une cure possible ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred
Dans : news:, Claude Schneegans disait :
Bonjour,
Bonjour,
J'ai plusieurs sites qui fonctionnent bien depuis des années. Depuis quelques temps, je détecte des erreur bizarres apparemment dues au fait que certaines pages appelées par un <FORM METHOD="POST" reçoivent en fait la requête en mode GET.
La variable CGI REQUEST_METHOD contient en effet GET au lieu de POST, et le scope de variable qui correspondent au FORM est vide :-(
Ça arrive peut-être une fois sur 200, le reste du temps, tout est normal.
Au risque de dire une bêtise, mais qu'est-ce qui peut m'empêcher d'appeler une page en GET plutôt qu'en POST ? Je suppose que POST est le comportement normal attendu après un clic sur un bouton de formulaire. Mais si j'appelle directement la page ciblée ? Le script doit gérer cela, non ?
Par contre, nous avons remarqué que le problème arrive tj avec des utilisateurs qui ont IE7.
D'où ma question : y aurait-il une problème connu avec le POST/GET sous IE7, et si oui, une cure possible ?
Je ne sais pas, mais si tu as un lien, je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc ... pour voir si ce GET ne serait pas le résultat d'une confusion de IE ... À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Dans : news:OLQBqlRpHHA.1240@TK2MSFTNGP04.phx.gbl,
Claude Schneegans disait :
Bonjour,
Bonjour,
J'ai plusieurs sites qui fonctionnent bien depuis des années.
Depuis quelques temps, je détecte des erreur bizarres apparemment dues
au fait que
certaines pages appelées par un <FORM METHOD="POST" reçoivent en fait
la requête en mode GET.
La variable CGI REQUEST_METHOD contient en effet GET au lieu de POST,
et le scope
de variable qui correspondent au FORM est vide :-(
Ça arrive peut-être une fois sur 200, le reste du temps, tout est
normal.
Au risque de dire une bêtise, mais qu'est-ce qui peut m'empêcher
d'appeler une page en GET plutôt qu'en POST ?
Je suppose que POST est le comportement normal attendu après un clic sur
un bouton de formulaire.
Mais si j'appelle directement la page ciblée ? Le script doit gérer
cela, non ?
Par contre, nous avons remarqué que le problème arrive tj avec des
utilisateurs qui ont IE7.
D'où ma question : y aurait-il une problème connu avec le POST/GET
sous IE7, et si oui, une cure possible ?
Je ne sais pas, mais si tu as un lien, je veux bien faire quelques
essais en bidouillant avec les réactualisations de page, les retours,
etc ... pour voir si ce GET ne serait pas le résultat d'une confusion de
IE ... À part un appel délibéré en GET, je ne vois pas d'autre cause
possible.
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
J'ai plusieurs sites qui fonctionnent bien depuis des années. Depuis quelques temps, je détecte des erreur bizarres apparemment dues au fait que certaines pages appelées par un <FORM METHOD="POST" reçoivent en fait la requête en mode GET.
La variable CGI REQUEST_METHOD contient en effet GET au lieu de POST, et le scope de variable qui correspondent au FORM est vide :-(
Ça arrive peut-être une fois sur 200, le reste du temps, tout est normal.
Au risque de dire une bêtise, mais qu'est-ce qui peut m'empêcher d'appeler une page en GET plutôt qu'en POST ? Je suppose que POST est le comportement normal attendu après un clic sur un bouton de formulaire. Mais si j'appelle directement la page ciblée ? Le script doit gérer cela, non ?
Par contre, nous avons remarqué que le problème arrive tj avec des utilisateurs qui ont IE7.
D'où ma question : y aurait-il une problème connu avec le POST/GET sous IE7, et si oui, une cure possible ?
Je ne sais pas, mais si tu as un lien, je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc ... pour voir si ce GET ne serait pas le résultat d'une confusion de IE ... À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Claude Schneegans
mais qu'est-ce qui peut m'empêcher d'appeler une page en GET plutôt qu'en POST ?
La methode est précisée explicitement dans la balise FORM : <FORM ACTION="myFormAction.cfm" METHOD ="POST"...
Naturellement, rien ne t'empêche de réécrire la page et de changer POST pour GET, mais je doute fort que mes clients qui me paient pour développer leur système de gestion de contenu s'amusent à ce genre de niaiseries ;-)
Mais si j'appelle directement la page ciblée ?
Même remarque, le système que je développe pour mes clients fonctionne bien, je ne vois pas pourquoi ils iraient appeler des pages en dehors du système, juste pour le plaisir planter le bousin ;-)
D'ailleurs, j'ai aussi la variable HTTP_REFERER qui montre bien que l'appel provient du formulaire normal.
mais qu'est-ce qui peut m'empêcher d'appeler une page en GET plutôt
qu'en POST ?
La methode est précisée explicitement dans la balise FORM :
<FORM ACTION="myFormAction.cfm" METHOD ="POST"...
Naturellement, rien ne t'empêche de réécrire la page et de changer POST
pour GET, mais je doute
fort que mes clients qui me paient pour développer leur système de
gestion de contenu
s'amusent à ce genre de niaiseries ;-)
Mais si j'appelle directement la page ciblée ?
Même remarque, le système que je développe pour mes clients fonctionne
bien, je ne vois pas pourquoi
ils iraient appeler des pages en dehors du système, juste pour le
plaisir planter le bousin ;-)
D'ailleurs, j'ai aussi la variable HTTP_REFERER qui montre bien que
l'appel provient du formulaire normal.
mais qu'est-ce qui peut m'empêcher d'appeler une page en GET plutôt qu'en POST ?
La methode est précisée explicitement dans la balise FORM : <FORM ACTION="myFormAction.cfm" METHOD ="POST"...
Naturellement, rien ne t'empêche de réécrire la page et de changer POST pour GET, mais je doute fort que mes clients qui me paient pour développer leur système de gestion de contenu s'amusent à ce genre de niaiseries ;-)
Mais si j'appelle directement la page ciblée ?
Même remarque, le système que je développe pour mes clients fonctionne bien, je ne vois pas pourquoi ils iraient appeler des pages en dehors du système, juste pour le plaisir planter le bousin ;-)
D'ailleurs, j'ai aussi la variable HTTP_REFERER qui montre bien que l'appel provient du formulaire normal.
Claude Schneegans
Je ne sais pas, mais si tu as un lien,
Impossible, il s'agit d'une application en intranet.
je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que rarement.
À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
Si, un bogue. C'est le navigateur qui envoie le fichier de données lors d'un submit, et c'est lui aussi qui met la valeur dans REQUEST_METHOD pour indiquer au serveur quoi faire avec. S'il n'y a pas la bonne valeur dans REQUEST_METHOD, le serveur n'ira même pas regarder s'il y a un fichier de données transmis. Et s'il n'y a pas la bonne valeur dans REQUEST_METHOD, je ne vois que le navigateur pour commettre l'impair.
Et le problème arrive toujours avec IE7, jamais avec IE6, bizarre quand même...
Je ne sais pas, mais si tu as un lien,
Impossible, il s'agit d'une application en intranet.
je veux bien faire quelques essais en bidouillant avec les
réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que rarement.
À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
Si, un bogue. C'est le navigateur qui envoie le fichier de données lors
d'un submit, et c'est lui aussi
qui met la valeur dans REQUEST_METHOD pour indiquer au serveur quoi
faire avec.
S'il n'y a pas la bonne valeur dans REQUEST_METHOD, le serveur n'ira
même pas regarder
s'il y a un fichier de données transmis.
Et s'il n'y a pas la bonne valeur dans REQUEST_METHOD, je ne vois que le
navigateur pour commettre l'impair.
Et le problème arrive toujours avec IE7, jamais avec IE6, bizarre quand
même...
Impossible, il s'agit d'une application en intranet.
je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que rarement.
À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
Si, un bogue. C'est le navigateur qui envoie le fichier de données lors d'un submit, et c'est lui aussi qui met la valeur dans REQUEST_METHOD pour indiquer au serveur quoi faire avec. S'il n'y a pas la bonne valeur dans REQUEST_METHOD, le serveur n'ira même pas regarder s'il y a un fichier de données transmis. Et s'il n'y a pas la bonne valeur dans REQUEST_METHOD, je ne vois que le navigateur pour commettre l'impair.
Et le problème arrive toujours avec IE7, jamais avec IE6, bizarre quand même...
Fred
Dans : news:, Claude Schneegans disait :
Mais si j'appelle directement la page ciblée ?
Même remarque, le système que je développe pour mes clients fonctionne bien, je ne vois pas pourquoi ils iraient appeler des pages en dehors du système, juste pour le plaisir planter le bousin ;-)
Ce n'est pas ce que je voulais dire :-) Simplement que techniquement c'est possible donc que cela doit être prévu. Je ne pratique pas PHP mais sur les quelques pages que j'ai développées en ASP.NET, je commence toujours par tester le type de requête pour éviter les plantages si les champs attendus lors d'un POST ne sont pas là.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Dans : news:erIgh1RpHHA.3644@TK2MSFTNGP02.phx.gbl,
Claude Schneegans disait :
Mais si j'appelle directement la page ciblée ?
Même remarque, le système que je développe pour mes clients fonctionne
bien, je ne vois pas pourquoi
ils iraient appeler des pages en dehors du système, juste pour le
plaisir planter le bousin ;-)
Ce n'est pas ce que je voulais dire :-)
Simplement que techniquement c'est possible donc que cela doit être
prévu. Je ne pratique pas PHP mais sur les quelques pages que j'ai
développées en ASP.NET, je commence toujours par tester le type de
requête pour éviter les plantages si les champs attendus lors d'un POST
ne sont pas là.
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Même remarque, le système que je développe pour mes clients fonctionne bien, je ne vois pas pourquoi ils iraient appeler des pages en dehors du système, juste pour le plaisir planter le bousin ;-)
Ce n'est pas ce que je voulais dire :-) Simplement que techniquement c'est possible donc que cela doit être prévu. Je ne pratique pas PHP mais sur les quelques pages que j'ai développées en ASP.NET, je commence toujours par tester le type de requête pour éviter les plantages si les champs attendus lors d'un POST ne sont pas là.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Fred
Dans : news:, Claude Schneegans disait :
Je ne sais pas, mais si tu as un lien,
Impossible, il s'agit d'une application en intranet.
OK.
je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que rarement.
Bon.
À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
Si, un bogue.
C'est bien ce que j'entendais par : «confusion de IE» :-)
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Dans : news:uvOb64RpHHA.4632@TK2MSFTNGP04.phx.gbl,
Claude Schneegans disait :
Je ne sais pas, mais si tu as un lien,
Impossible, il s'agit d'une application en intranet.
OK.
je veux bien faire quelques essais en bidouillant avec les
réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que
rarement.
Bon.
À part un appel délibéré en GET, je ne vois pas d'autre cause
possible.
Si, un bogue.
C'est bien ce que j'entendais par : «confusion de IE» :-)
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Impossible, il s'agit d'une application en intranet.
OK.
je veux bien faire quelques essais en bidouillant avec les réactualisations de page, les retours, etc
J'ai fait tous ces essais, sans succès. le problème n'arrive que rarement.
Bon.
À part un appel délibéré en GET, je ne vois pas d'autre cause possible.
Si, un bogue.
C'est bien ce que j'entendais par : «confusion de IE» :-)
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Claude Schneegans
Je ne pratique pas PHP mais sur les quelques pages que j'ai développées en ASP.NET,
Je suis en ColdFusion, c'est équivalent à PHP ou ASP, mais je ne crois pas que le problème vienne de là.
je commence toujours par tester le type de requête pour éviter les plantages si les champs attendus lors d'un POST ne sont pas là.
C'est précisément ce que je fais, en fait, pour n'importe quel type d'erreur ou d'anomalie. Dans le but justement de corriger les erreurs. Et j'enregistre dans une table tout ce qui n'est pas normal, avec tout le contexte. Ici, c'est plutôt du genre anomalie. Mon code envoie un formulaire en methode POST, mais le serveur le reçoit en methode GET, chercher l'erreur ! C'est ça le problème. Ce que je veux, c'est qu'il n'arrive pas.
C'est techniquement impossible, à moins de faire exprès, ce qui revient au même, de la part de mes clients. La page n'est pas publique, il n'y a que 3 usagers qui y ont accès.
Je ne pratique pas PHP mais sur les quelques pages que j'ai
développées en ASP.NET,
Je suis en ColdFusion, c'est équivalent à PHP ou ASP, mais je ne crois
pas que le problème vienne de là.
je commence toujours par tester le type de requête pour éviter les
plantages si les champs attendus lors d'un POST ne sont pas là.
C'est précisément ce que je fais, en fait, pour n'importe quel type
d'erreur ou d'anomalie.
Dans le but justement de corriger les erreurs.
Et j'enregistre dans une table tout ce qui n'est pas normal, avec tout
le contexte.
Ici, c'est plutôt du genre anomalie.
Mon code envoie un formulaire en methode POST, mais le serveur le reçoit
en methode GET, chercher l'erreur !
C'est ça le problème. Ce que je veux, c'est qu'il n'arrive pas.
C'est techniquement impossible, à moins de faire exprès, ce qui revient
au même, de la part de mes clients.
La page n'est pas publique, il n'y a que 3 usagers qui y ont accès.
Je ne pratique pas PHP mais sur les quelques pages que j'ai développées en ASP.NET,
Je suis en ColdFusion, c'est équivalent à PHP ou ASP, mais je ne crois pas que le problème vienne de là.
je commence toujours par tester le type de requête pour éviter les plantages si les champs attendus lors d'un POST ne sont pas là.
C'est précisément ce que je fais, en fait, pour n'importe quel type d'erreur ou d'anomalie. Dans le but justement de corriger les erreurs. Et j'enregistre dans une table tout ce qui n'est pas normal, avec tout le contexte. Ici, c'est plutôt du genre anomalie. Mon code envoie un formulaire en methode POST, mais le serveur le reçoit en methode GET, chercher l'erreur ! C'est ça le problème. Ce que je veux, c'est qu'il n'arrive pas.
C'est techniquement impossible, à moins de faire exprès, ce qui revient au même, de la part de mes clients. La page n'est pas publique, il n'y a que 3 usagers qui y ont accès.
Michel Claveau
Bonsoir !
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à la volée ?
-- @-salutations
Michel Claveau
Bonsoir !
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à la
volée ?
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à la volée ?
-- @-salutations
Michel Claveau
Claude Schneegans
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à la volée ?
Ça ne serait pas impossible, mais dans ce cas, j'aurais le problème dans tous les cas, pas une fois de temps en temps. En fait, mon système deviendrait complètment inutilisable, et à peu près tout l'Internet à partir du même réseau. De plus, mes clients ont le même fournisseur qu'un autre de mes clients qui utilise le même système, et eux ne semble pas avoir de problème, même avec IE7. Bizarre...
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à
la volée ?
Ça ne serait pas impossible, mais dans ce cas, j'aurais le problème dans
tous les cas, pas une fois de temps en temps.
En fait, mon système deviendrait complètment inutilisable, et à peu près
tout l'Internet à partir du même réseau.
De plus, mes clients ont le même fournisseur qu'un autre de mes clients
qui utilise le même système, et eux ne semble pas avoir de problème,
même avec IE7.
Bizarre...
N'y aurait-il pas un proxy, qui pourrait modifier la requête HTTp à la volée ?
Ça ne serait pas impossible, mais dans ce cas, j'aurais le problème dans tous les cas, pas une fois de temps en temps. En fait, mon système deviendrait complètment inutilisable, et à peu près tout l'Internet à partir du même réseau. De plus, mes clients ont le même fournisseur qu'un autre de mes clients qui utilise le même système, et eux ne semble pas avoir de problème, même avec IE7. Bizarre...
