header("Location:....") en mode POST

Bonjour

Je voudrais transmettre des données en POST à une page. Comment
utiliser la fonction header pour effectuer cette manipulation ?

Bonjour,

A priori, ça n'est pas trop possible de forcer un navigateur à faire un post
depuis le serveur.

Tu pourrais faire les manipulations dans l'autre sens :
- tu fais ta redirection header("Location:..");
- dans ta page de redirection, tu crées une requête POST en Ajax et tu la
balances.

Sinon il faut choisir une autre solution.

(j'ai déjà eu le problème pour une création de commande dans une boutique
en ligne, finalement, j'ai utilisé un parcours client un peu différent...)

Cordialement,
Philippe Le Van
--
Outils de débug ajax pour IE, FF et Safari : http://www.kitpages.fr/ajax_tools.php

Je voudrais transmettre des données en POST à une page.
Comment utiliser la fonction header pour effectuer cette manipulation ?

Je me trompe peut-être, mais j'ai l'impression que tu es tombé dans
l'erreur que font beaucoup de gens, qui croient qu'après avoir reçu
une requête qui modifie des valeurs en base de données il faut dire
au navigateur de redemander une *autre* URL sur le même site.

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

<cit.>
... vous ne devriez pas utiliser header("Location:...script2.php") pour
rediriger entre deux scripts de votre site. Cela imposerait un
aller-retour inutile entre le serveur et le navigateur (traffic réseau
inutile et dégradation des temps de réponse de votre site proportionnels
à la vitesse de connexion de l'internaute). Il est bien plus rapide
d'ajouter simplement dans le code php les instructions :
require("script2.php"); exit();
</cit.>


Ce point étant rappelé (mais tu peux aussi consulter les archives du
groupe car la question revient très souvent), je dirai que :
- si tu as besoin de faire un POST vers un autre site que le tien, tu
peux essayer de voir du côté de <http://fr.php.net/curl> ;
- si tu dois vraiment répondre un header("Location: ...") vers un autre
site que le tien, ce sera un GET et pas un POST ;
- si tu veux répondre un header("Location: ...") sur le même site, c'est
que tu n'as pas bien compris ce que j'essayais de rappeler au début de
cet article. Relire <http://faqfclphp.free.fr/#rub2.11>.

Tu pourrais faire les manipulations dans l'autre sens :
- tu fais ta redirection header("Location:..");
- dans ta page de redirection, tu crées une requête POST en Ajax et tu la
balances.

Magnifique !!!! De l'orfèvrerie dans l'incompréhension totale de ce qui se
passe (ou le mépris le plus total pour les temps de réponse et la
consommation de bande passante, ce qui ne serait pas mieux).

Convention : Client -> Serveur
# allez, on clique (malheureux ! fallait pas !)
GET/POST data -> rediriger.php
# ah non, location, c'était ailleurs, flûte.
<- header : location
# ah alors c'était où ? Bah vers un truc qui génèrera du JS pour faire le
#post.
data->generateur_ajax.php
#ah ouais, donc on génère du JS+data pour pouvoir faire du post
<-data+JS
#bon alors on en fait quoi de ce truc ?
#Ah merde fallait envoyer ailleurs en post.
POST data-> bon_endroit.php

Ouf, les données sont arrivées à l'endroit où on aurait pu directement les
envoyer en se les trimballant CINQ (5) PING/PONG au lieu d'UN ENVOI ! :-))
J'adore, je la garde pour mon bêtisier personnel :-))) Ca frise le GNU.

(Accessoirement, si le client merde sur le JS, on est foutus).

Outils de débug ajax pour IE, FF et Safari :
http://www.kitpages.fr/ajax_tools.php

Ce genre de toolkits va inclure des compteurs d'allers-retours inutiles
des mêmes données ou pas ? Apparement, ça manque.

Ah, et au fait, sauf dans le cas de données confidentielles, pour éviter
qu'elles soient écrites dans les logs, GET ou POST, on s'en cogne, c'est
pareil, il n'y a que l'encodage qui change (vieux débat).

JG

- tu fais ta redirection header("Location:..");
- dans ta page de redirection, tu crées une requête POST en Ajax et tu la
balances.

Splendide ! Ça fait donc trois requêtes au lieu d'une, et cela nécessite
impérativement que le visiteur ait un navigateur récent avec JavaScript
activé et XMLHttpRequest implémenté.

Avant d'en arriver à de telles extrémités, il faudrait d'abord s'assurer
que dric-li a vraiment besoin de requêtes POST réparties sur deux sites
internet différents. Personnellement je n'ai *jamais* vu le cas.

- tu fais ta redirection header("Location:..");
- dans ta page de redirection, tu crées une requête POST en Ajax et tu la
balances.

John GALLET, le 11/12/2006 15:32, a répondu :

Magnifique !!!! [...]

Quant à moi, le 11/12/2006 15:47, j'ai répondu :

Splendide ! [...]

Je vous jure que je n'avais pas lu la réponse de John avant d'envoyer
la mienne. Mais quelque chose me dit qu'on est d'accord...

dric-li wrote:

Bonjour

Je voudrais transmettre des données en POST à une page.
Comment utiliser la fonction header pour effectuer cette manipulation ?

Merci à tous pour vos contributions.
Il s'agit en effet d'envoyer une requête POST vers un serveur sécurisé de
paiement en ligne.
En menant plus loin mes investigations, j'ai vu qu'on peut utiliser (dans ce
cas précis) la fonction fsockopen...

--
+----------------------------------------------------+
Linux user #347847 registered on http://counter.li.org
+----------http://www.mandrivalinux.com -------------+

Il s'agit en effet d'envoyer une requête POST vers un serveur sécurisé de
paiement en ligne.

Ok. Merci de le préciser.

En menant plus loin mes investigations, j'ai vu qu'on peut utiliser (dans ce
cas précis) la fonction fsockopen...

Est-ce que les fonctions curl (lien déjà donné) ne seraient pas plus
simples ?

En menant plus loin mes investigations, j'ai vu qu'on peut utiliser (dans ce
cas précis) la fonction fsockopen...

Juste pour ma culture perso, pourquoi "dans ce cas précis" ? On peut
toujours utiliser fsockopen pour faire une requête http distante... quel
que soit le cas, donc ?

Est-ce que les fonctions curl (lien déjà donné) ne seraient pas plus
simples ?

Ni l'un ni l'autre ne sont souhaitables pour deux raisons :

- c'est extrêmement perturbant pour l'utilisateur non averti, qui se
retrouve d'un seul coup sans comprendre à dégainer la carte bleue sur un
site nouveau sans aucune explications. Alors que si on a une étape
intermédiaire où on lui explique que pour garantir la confidentialité de
la transaction, il va quitter le site actuel pour aller chez une grande
banque internationale qui garantit la sécurité etc, c'est beaucoup plus
cohérent. Cet argument est totalement subjectif.

- ça casse le principe du tiers de confiance. Il ne doit pas y avoir de
dialogue direct entre le site marchand et la banque. C'est une affaire
entre le client et la banque, par définition même du tiers de confiance,
et c'est ce qui impose l'utilisation de la clef de scellement : sinon, on
transmettrait DIRECTEMENT la bonne somme à payer à la banque en lui
parlant en direct. La banque communiquera ensuite en asynchrone les
résultats, et fournit un moyen de revenir au site marchand (en général
deux liens, le lien pour annuler et le lien en fin de transaction).

Enfin, ceci doit se faire sur SSL, ce qui IMPOSE un dialogue direct
entre le navigateur du client et le site sécurisé de paiement, sinon on
serait dans le cas d'un SITM :-) (Site In The Middle).

Oubliez toute idée semblable à du "relaying" qui redirigerait un flux
venant du site sécurisé vers le client final au travers du middle-tiers
(php) c'est à la fois mauvais et fort heureusement voué à l'échec (et
c'est bien ce que ferait un dialogue socket, curl ou include distant).

La seule solution pour éviter un clic au client final futur payeur (parce
que c'est de ça qu'on parle, un clic pas plus, "tout ça pour un clic en
moins et quelques électrons en plus" ;-) ) c'est d'avoir un modèle
client/serveur connecté style 2 tiers, par une applet ou en le simulant
par js/XMLHttpRequest aka ajax (mais en direct, pas avec un header
location au milieu !)

a++;
JG