En quoi une redirection en réponse d'un POST poserait problème ?
Personnellement, j'utilise cela au quotidien et ça fonctionne sans problème sur tous les navigateurs que l'on doit gérer (jusqu'à IE7 inclus).

Je m'abstiens de voter en attendant

La direction 302 va transformer le POST en GET et par la même occasion perdre toutes les variables. Du coup, la page sensée traiter le formulaire va recevoir une requête vide...

@Request c'est un problème d'implémentation client, dans ce cas, pas un problème serveur. Si le client ne reprend pas les champs dans sa nouvelle requête, en quoi est-ce le problème du serveur?

La RFC est claire à ce sujet, notamment le troisième paragraphe:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

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.

On ne parle pas de transformer une requête en une autre, il ne s'agit que de la réponse.
Normalement, tu dois pouvoir faire une redirection 302 après réception des données POST, elles ont très bien pu être traitées entre temps et ça redirige simplement vers une page avec un message ou la page d'accueil.
Il y a vraiment PEBKAC et incompétence quand la redirection 302 se fait en boucle :D (Non non, ça m'arrive jamais innocent)

J'allais poster le même commentaire.

Je rajouterais que c'est même une pratique recommandée : le serveur fait le traitement du POST, puis envoie un 302 pour rediriger vers une page qui dit en gros "Succès de la requête, merci".

Côté client, ça permet d'éviter qu'en faisant F5, le client se retrouve avec une boîte de dialogue du type "Pour actualiser la page, des données doivent être renvoyées. Voulez-vous renvoyer ces données ?".

Côté serveur, ça évite les doubles soumissions en cas d'actualisation.

C'est donc très bien de faire ça, et je le faisais déjà en 2002, donc ça marche très bien sur tous les navigateurs. En attendant des explications de l'auteur, je m'abstiens également de voter.

« If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request »
« 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. »

Autrement dit : la redirection 302 n'est pas sensé marcher en POST mais la plupart des navigateurs transforment la requête en GET.
La RFC donne raison à Request.

Les explications sont données juste en dessous par Request (voir la RFC dans un autre post plus loin).

Merci de lire tous les commentaires avant de dire « Je comprends pas » !

J'avais vu quelque part l'histoire de quelqu'un qui avait le même genre de problèmes pour un remboursement. Il avait écrit un script qui envoyait automatiquement un email de relance tout les dix minutes. Il a été remboursé en quelques heures.

j'ai hésité avec CTLP car vu la bande d'incompétents auxquels tu as l'air d'avoir eu affaire, je pense que tu aurais du passer au recommandé directement

En effet ; je ne sais pas si c'est ta source, mais j'avais lu ça sur Slashdot.

La note de la rfc explique au contraire que tous les navigateurs traitent une réponse 302 en faisant un GET sur l'URL donné dans le header location.

Donc le comportement des navigateurs a fait changer la RFC où deux nouveaux codes ont été introduits pour gérer tous les cas sans ambiguïté.

Ça confirme que tous les navigateurs gèrent les réponses 302 en réponse à un POST sans aucun problème, contrairement à ce qu'affirme l'auteur du pebkac.