Discussion :

[Nicolas.Cogi]

Hello

Je recherche une information sur la gestion des requetes POST avec mod_rewrite.

Pour l'exemple, j'aimerai rewrité une URL GET comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://site/Appli/Action -> http://site/Appli/Page.php?a=Action

Pour ca, pas de probleme.

En revanche, comment m'y prendre pour remplir le paramètre "a" précédent directement dans les paramètres POST ?

Pour codifier ce que je veux faire (rien à voir avec une syntaxe de rewriting, hein ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
  if (Method == 'POST')
  {
    rewrite http://site/Appli/Action -> http://site/Appli/Page.php
    PostParams += 'a=Action'
  }

Je n'ai pas réussi à trouver d'info sur la gestion des POST avec mod_rewrite, si quelqu'un a une idée !

Merci !

[_Mac_]

A ma connaissance, c'est pas possible car mod_rewrite ne permet de travailler que sur la ligne de requête HTTP, là où figure l'URL demandée. La seule solution c'est d'utiliser mod_rewrite pour passer par un script intermédiaire qui fait éventuellement un second POST.

[Nicolas.Cogi]

Achh !! Mais ca ne me convient pas du tout, comme réponse !!
Bon, tant pis, je vais tacher de reflechir à mon affaire et trouver un contournement.

Merci beaucoup pour ton avis éclairé !

(je laisse le post ouvert quelques jours au cas où...)

[_Mac_]

Achh !! Mais ca ne me convient pas du tout, comme réponse !!

Ben ouais mais c'est la seule réponse !!

Pourquoi tu veux ajouter un paramètre POST ? Pourquoi en GET c'est pas bon ?

[Nicolas.Cogi]

Parce qu'on m'adresse des requetes POST pour mes gros formulaires.

Pour expliquer plus clairement :

Le framework utilisé (XMLRAD, voir forum dédié à ce sujet) permet la création d'appli web tournant en ISAPI, ApacheAPI, .NET, J2EE ou PHP. Le truc pratique, c'est que (presque ) rien ne change entre les plateformes : le framework encapsule toutes les différences. Il faudra bien sûr recoder les regles de gestion fonction du language choisi (Delphi ou C# ou Java ou PHP ou ...) mais sinon, tout reste pareil : fichiers de conf, description des traitements sur les données, XSL de génération des pages html, ...

Les URL pour de l'isapi sont de la forme http://localhost/MonProjetBin/MonProjet.dll/MonAction

En revanche, pour du PHP, par exemple, l'URL ressemble à http://localhost/MonProjetBin/XMLSer...tion=MonAction

Tout mon probleme est de permettre à un developpeur de passer d'un type de projet à un autre facilement, ISAPI vers PHP par exemple, pour quelconque raison (changement d'archi serveur, ... tout ce qu'on peut imaginer...) et donc de minimiser au maximum les changements à apporter dans les documents XSL générant les pages HTML.

Pour la partie de l'URL /MonProjetBin/MonProjet.dll/ ou /MonProjetBin/XMLServer.php, pas de problème, c'est centralisé dans un fichier de conf.

La où ca se corse, c'est pour les actions de formulaires (et j'en ai pleins, parfois avec des fichiers uploadé, d'où l'obligation d'un POST)

en PHP ca me donne obligatoirement un form comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
<form action="/MonProjetBin/XMLServer.php" method="POST">
  <input type="hidden" name="XMLC_Action" value="MonAction" />

J'ai donc un soucis pour mes chers développeurs qui veulent passer de ISAPI vers PHP, puisqu'ils sont alors obligés de repasser sur chacun des formulaires pour rajouter ce champ hidden et modifier l'attribut action...

Je pensais donc à l'URL rewriting pour éviter ca et permettre le switch d'environnement plus facilement.

[_Mac_]

Pourquoi ajouter un champ hidden ? Pourquoi ne pas mettre directement ton action dans l'URL de post du formulaire ? Si j'ai bien compris, l'effort est alors nul car cette URL est tirée directement de ton fichier de conf.

La difficulté, c'est de récupérer la valeur de l'action, mais n'est-ce pas possible de toujours partir du principe que cette action se trouve dans l'URL et qu'il faut faire un request.getParameter() en J2EE ou $_GET[] en PHP ?

Je sais pas si je suis clair...