IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Apache Discussion :

Variables POST non-transmises par .htaccess


Sujet :

Apache

  1. #1
    Futur Membre du Club
    Profil pro
    Webmaster
    Inscrit en
    Juillet 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Webmaster

    Informations forums :
    Inscription : Juillet 2012
    Messages : 6
    Points : 5
    Points
    5
    Par défaut Variables POST non-transmises par .htaccess
    Bonjour,

    Je POST des variables avec un formulaire, mais la condition présente dans mon .htaccess bloque le passage des variables :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    	RewriteCond %{HTTP_HOST} ^monsite\.com$
    	RewriteRule ^(.*) http://www.monsite.com/$1 [QSA,L,R=301]

    Un post similaire existe mais je n'y trouve pas ma solution : http://www.developpez.net/forums/d84...-donnees-post/

    j'ai tenté d'enlever "http" dans la ligne du .htaccess en remplacant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    RewriteRule ^(.*) http://www.monsite.com/$1 [QSA,L,R=301]
    par
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    RewriteRule ^(.*) www.monsite.com/$1 [QSA,L,R=301]
    mais les liens ne fonctionnent plus.


    d'autres post similaires existent mais je n'y trouve pas non plus :
    http://forum.modrewrite.com/viewtopic.php?f=4&t=42461
    http://forum.webrankinfo.com/htacces...t-t169387.html

    Si quelqu'un peut m'aider ? merci beaucoup !!!

  2. #2
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Ma réponse de l'époque n'était pas forcément très explicative. En fait, ce que tu cherches à faire (rediriger une requête POST) n'est pas faisable seulement avec Apache. C'est un problème connu du protocole HTTP et qui est décrit dans la RFC d'ailleurs, si j'ai bonne mémoire (ce dont je doute ) et contre lequel on ne peut pas lutter. HTTP fonctionne sur le principe simple : une requête, une réponse. Chaque réponse est accompagnée d'un code (le statut) qui donne du détail sur le traitement de la requête. Les statuts sont univoques : ils ne signifient qu'une et unique chose. Ainsi, si le navigateur reçoit une réponse avec un statut 301 (redirection permanente), c'est pour lui dire d'aller voir ailleurs et c'est tout. Ca ne dit strictement rien sur le fait que la requête POST en elle-même a été correctement traitée. Et donc, dans ce cas, qu'est-ce que le navigateur est-il censé faire ? Faire de nouveau un POST ou bien considéré que le traitement de la requête a réussi et faire un simple GET ? Eh bien, on ne sait pas, et pour des raisons de sécurité, on a tendance à préférer la seconde solution et ne pas refaire le POST. Moralité : il faut contourner le problème.

    Comment ? Et bien tout simplement en faisant explicitement en sorte que le navigateur fasse un POST sur l'URL cible, donc répondre avec un code 200 (traitement OK), lui renvoyer de nouveau un formulaire avec la bonne URL cible et forcer automatiquement le POST avec du JavaScript. Et voilà comment on s'en sort.

    Dans ton cas, ça peut paraître lourd. La question est de savoir pourquoi un navigateur commencerait d'emblée par une requête POST sur http://monsite.com/... sans être d'abord passé par une page simple accédée en GET sur cette même URL http://monsite.com/ ? Autrement dit, sur une navigation directe, un navigateur demande simplement (un GET) une page de http://monsite.com/ qui est alors redirigée (code 301) vers http://www.monsite.com/. Là, ça ne pose pas de problème car on partait d'un GET pour refaire un GET. Et une fois qu'on est sur la bonne URL de base, tout va bien. Donc pourquoi ne tombe-t-on pas sur ce schéma ?

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  3. #3
    Futur Membre du Club
    Profil pro
    Webmaster
    Inscrit en
    Juillet 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Webmaster

    Informations forums :
    Inscription : Juillet 2012
    Messages : 6
    Points : 5
    Points
    5
    Par défaut
    Merci beaucoup pour tes informations Mac.
    je n'ai pas donné suffisamment d'infos je pense.

    lorsque je suis sur la page du formulaire, son URL est :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://www.monsite.com/blog/admin/
    et cette URL est réécrite par le .htaccess en :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    #RewriteRule ^blog/admin/$ index.php?menu=blog&section=admin [L]
    RewriteRule ^blog/admin/$ index.php?menu=blog&section=admin [QSA,L]
    (j'ai ajouté le drapeau QSA sans succès)

    donc si je comprend ton explication (mais j'ai un gros doute ),
    je suis sur une page de formulaire en GET
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    http://www.crea7.agency/blog/admin/
    rééécrite en
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     index.php?menu=blog&section=admin
    et j'envoie mes variables POST à la page d'index en faisant un GET
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     index.php?menu=blog&section=admin
    accompagné des variables en POST.
    l'index.php est censé détecter ces variables POST, en faire la vérification, et rediriger l'administration, mais les variables sont vides.

    Comme tu l'explique, on partait d'un GET pour refaire un GET, donc je ne comprend pas l'origine du blocage .

  4. #4
    Futur Membre du Club
    Profil pro
    Webmaster
    Inscrit en
    Juillet 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Webmaster

    Informations forums :
    Inscription : Juillet 2012
    Messages : 6
    Points : 5
    Points
    5
    Par défaut
    Résolu :

    l'origine du blocage venait de la ligne présente dans mon header :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <base href="http://monsite.com/" >
    je l'ai corrigée par celle-ci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <base href="http://www.monsite.com/" >
    L'adresse venant d'une variable dans un fichier auquel je ne touche que rarement,
    je n'y faisais pas attention durant mon analyse du header.

    Merci en tout cas, Mac !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Variable non transmise (post) sur serveur distant
    Par mikl86 dans le forum Langage
    Réponses: 2
    Dernier message: 20/03/2011, 12h27
  2. variables POST non reçues sur le serveur
    Par jacquesprogram dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 10/12/2009, 16h45
  3. [PDF] variable post non transmise
    Par Enhide dans le forum Bibliothèques et frameworks
    Réponses: 11
    Dernier message: 27/05/2008, 15h32
  4. Liste non passee par methode post
    Par Fablondon dans le forum ASP
    Réponses: 5
    Dernier message: 09/05/2006, 13h57
  5. Réponses: 9
    Dernier message: 15/03/2006, 10h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo