redirect apres script

J'ai une page ipn.php sur laquelle est effectuée une redirection après
un paiement Paypal
cette page cointient un script qui met à jour une base de donnée..
pas de problème de ce coté tout fonctionne...
mais une fois ce script executé (de façon transparente pour
l'utilisateur puisqu'il n'y a rien à afficher) comment faire pour
automatiquement rediriger vers lune autre page... ?

Le plus propre est d'utiliser un require() au lieu d'une redirection
HTTP (déménageur, toussa). Voir : <http://faqfclphp.free.fr/#rub2.11>.

le header redirect ne peut être mis qu'en début de page .... pas à la fin

Si *vraiment* tu n'as rien affiché, alors les entêtes HTTP peuvent
toujours être envoyés, même après l'exécution d'un script de 1000
lignes. Voir <http://faqfclphp.free.fr/#rub2.12>.

Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.

Quand je veux faire une redirection apres l'exécution d'un script et
meme si le header est déja bien passé, je me suis fait une petite
fonction :

function redirection($url){
echo"<script language="JavaScript">";
echo"document.location.href="$url" ";
echo"</script>";
}

ça crée un code javascript qui fait une redirection auto :)

C'est tout simpel et ça marche bien

H-Barre

J'ai une page ipn.php sur laquelle est effectuée une redirection après un
paiement Paypal
cette page cointient un script qui met à jour une base de donnée..
pas de problème de ce coté tout fonctionne...
mais une fois ce script executé (de façon transparente pour l'utilisateur
puisqu'il n'y a rien à afficher) comment faire pour automatiquement rediriger
vers lune autre page... ?
le header redirect ne peut être mis qu'en début de page .... pas à la fin
j'ai déjà fiat des redirections, mais il y avait une form est une action de
l'utilisateur qui proqovuait un refresh....
pas dans ce cas de figure :-((

pni.php
<?
script de mise à jour de la base de données à partir des données _POST de
Paypal
...
(aucun affichage, aucune intervention de l'utilisateur)
..
redirection automatique vers une page ? -> index.php
?>

Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.

C'est complètement stupide. Faire un redirect après un POST est au
contraire une très bonne pratique, qui évite les problèmes de
resoumission du formulaire si l'utilisateur rafraichit la page, ou
d'adresse incorrecte dans la barre d'adresse du navigateur.
Si votre banque suivait votre conseil, par exemple, et revenait à la
situation de votre compte après un virement effectué sans faire de
redirect, et si vous rafraichissiez la page, vous vous prendriez un
avertissement de la part de votre navigateur (incompréhensible pour la
plupart des utilisateurs), et vous réeffectueriez le virement.
Lire par exemple http://tim.digicol.de/weblog/archives/2005/07/18/521 ou
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost

De plus, au contraire de ce que la FAQ indique, un redirect n'a pas
grand chose à voir avec un meta refresh, qui doit toujours être évité,
parce qu'il casse le bouton back du navigateur

Lire à ce propos http://www.w3.org/QA/Tips/reback ou
http://en.wikipedia.org/wiki/META_refresh

Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.

C'est complètement stupide. Faire un redirect après un POST est au
contraire une très bonne pratique, [...]

Tiens, c'est vrai. La question est si souvent posée pour un GET, que je
n'avais pas fait gaffe qu'ici il s'agissait d'un POST. Je suis d'autant
plus impardonnable que Josselin parlait de paiement (donc forcément un
POST). Qui plus est, j'ai probablement confondu une redirection (code
307 par exemple) avec un simple header("Location: ..."). Tout faux,
donc.

Lire par exemple http://tim.digicol.de/weblog/archives/2005/07/18/521 ou
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost

Merci.

De plus, au contraire de ce que la FAQ indique, un redirect n'a pas
grand chose à voir avec un meta refresh, qui doit toujours être évité,
parce qu'il casse le bouton back du navigateur

Lire à ce propos http://www.w3.org/QA/Tips/reback ou
http://en.wikipedia.org/wiki/META_refresh

Le header("Location: ...") tout seul ne casse pas le bouton back, lui
aussi ?

Mais surtout, évite le header("Location:...") quand tu le peux.
Relire <http://faqfclphp.free.fr/#rub2.11>.

C'est complètement stupide. Faire un redirect après un POST est au
contraire une très bonne pratique, qui évite les problèmes de

Mais qui en créé d'autres. Un redirect c'est un GET, et les mélanges
GET/POST dans les redirects... C'est pour ca qu'on a inventé le code 307.

Si votre banque suivait votre conseil, par exemple, et revenait à la
situation de votre compte après un virement effectué sans faire de
redirect, et si vous rafraichissiez la page, vous vous prendriez un
avertissement de la part de votre navigateur (incompréhensible pour la
plupart des utilisateurs), et vous réeffectueriez le virement.

Mauvais code applicatif. Il y a des solutions pour gérer le rechargement.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Qui plus est, j'ai probablement confondu une redirection (code
307 par exemple) avec un simple header("Location: ..."). Tout faux,
donc.

L'en-tête Location ne peut exister que pour une redirection !
(le code 201 n'est pas vraiment utilisé en pratique)

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost

Que de bêtises dans cet article. Un florilège :
«The answer to double submit problem is redirection»

«caching must be prohibited for web applications»

«Prohibit caching of application pages. Insert

<meta HTTP-EQUIV="Pragma" content="no-cache"> and
<meta HTTP-EQUIV="Expires" content="-1">
»
(encore un mauvais usage de la balise meta et une mauvaise valeur pour
l'en-tête Expires!)

«There are two choices to keep POST data: either to transfer it a
redirecting response and the in a GET request, or to store it on the
server.»
(transformer un POST en GET ... quelle grande idée !)

En résumé j'encourage vraiment à ne pas prendre du tout en compte les
soi-disant bonnes pratiques de ce papier, qui sont tout sauf bonnes.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

«There are two choices to keep POST data: either to transfer it a
redirecting response and the in a GET request, or to store it on the
server.»
(transformer un POST en GET ... quelle grande idée !)

transfer != transform

JB.

Mais surtout, évite le header("Location:...") quand tu le peux.

Relire <http://faqfclphp.free.fr/#rub2.11>.

C'est complètement stupide. Faire un redirect après un POST est au
contraire une très bonne pratique, qui évite les problèmes de

Mais qui en créé d'autres.
Ah bon? Lesquels?

Un redirect c'est un GET, et les mélanges

GET/POST dans les redirects... C'est pour ca qu'on a inventé le code 307.

Ben oui, parce que, comme le dit la RFC: "Note: RFC 1945 and RFC 2068
specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client."

Le code 302 est donc, dans les faits, utilisé pour des redirections
automatiques et des "transformations" de posts en gets. C'est peut-être
abusif, mais c'est comme ça. Et la raison en est, AMA, que les codes 303
et 307 n'existent PAS dans HTTP 1.0.
De toute façon, quel que soit le code, 302 ou 307, le résultat est le
même: c'est une bonne pratique de faire un redirect après un post, pour
éviter les problèmes d'avertissments incompréhensibles pour
l'utilisateur, les problèmes de rafraichissements qui repostent des
requêtes non-idempotentes, et les problèmes d'adresse dans la barre
d'adresse qui ne reflètent pas réellement l'adresse de la ressource
présentée à l'uilisateur. Vous pouvez rester dans votre tour d'ivoire si
vous le désirez, il n'empêche que c'est un pattern qui est préconisé par

Si votre banque suivait votre conseil, par exemple, et revenait à la
situation de votre compte après un virement effectué sans faire de
redirect, et si vous rafraichissiez la page, vous vous prendriez un
avertissement de la part de votre navigateur (incompréhensible pour la
plupart des utilisateurs), et vous réeffectueriez le virement.

Mauvais code applicatif. Il y a des solutions pour gérer le rechargement.

Oui. Et la meilleure, c'est d'utiliser un redirect après un post.

JB.

Mauvais code applicatif. Il y a des solutions pour gérer le rechargement.
Oui. Et la meilleure, c'est d'utiliser un redirect après un post.

Soit un script écrit avec wget ou curl qui balance en boucle infinie les
mêmes arguments à votre super-script dôté de son header:Location. Il va
vous gérer le refresh combien de fois ? zéro. Arrêtez de croire qu'il
n'y a que des navigateurs et des utilisateurs honnêtes dans la vie. Il y
a des cas où le redirect après traitement *peut probablement* être
*toléré* comme solution (cas où l'utilisateur ou l'attaquant n'ont pas
intérêt à jouer sur le refresh) mais ce ne sera *jamais* une solution
universelle.

a++;
JG