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:

---

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:

---

RewriteRule ^(.*) http://www.monsite.com/$1 [QSA,L,R=301]

---

par

Code:

---

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 !!! :calim2:

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 :mouarf:) 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 ?

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:

---

http://www.monsite.com/blog/admin/

---

et cette URL est réécrite par le .htaccess en :

Code:

---

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 :mrgreen:),
je suis sur une page de formulaire en GET

Code:

---

http://www.crea7.agency/blog/admin/

---

rééécrite en

Code:

---

index.php?menu=blog&section=admin

---

et j'envoie mes variables POST à la page d'index en faisant un GET

Code:

---

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 :weird:.

Résolu :

l'origine du blocage venait de la ligne présente dans mon header :

Code:

---

<base href="http://monsite.com/" >

---

je l'ai corrigée par celle-ci :

Code:

---

<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 !