it-swarm-eu.dev

Tableau $ _POST mystérieusement vide

J'ai la page HTML/PHP suivante:

<?php
if(empty($_SERVER['CONTENT_TYPE'])) {
    $type = "application/x-www-form-urlencoded";
    $_SERVER['CONTENT_TYPE'] = $type;
}

echo "<pre>";
var_dump($_POST);
var_dump(file_get_contents("php://input"));
echo "</pre>";
?>

<form method="post" action="test.php">
<input type="text" name="test[1]" />
<input type="text" name="test[2]" />
<input type="text" name="test[3]" />
<input type="submit" name="action" value="Go" />
</form>

Comme vous pouvez le voir, le formulaire sera soumis et la sortie attendue est un tableau POST avec un tableau contenant les valeurs remplies et une entrée "action" avec la valeur "Go" (le Cependant, quelles que soient les valeurs que j'entre dans les champs, le résultat est toujours:

array(2) {
  ["test"]=>
  string(0) ""
  ["action"]=>
  string(2) "Go"
}
string(16) "test=&action=Go&"

D'une manière ou d'une autre, le tableau nommé test est vidé, la variable "action" le fait.

J'ai utilisé l'extension Live HTTP Headers pour Firefox pour vérifier si les champs POST sont envoyés, et ils le font. Les informations pertinentes des Live HTTP Headers (avec a, b et c remplies comme valeurs dans les zones de texte):

Content-Type: application/x-www-form-urlencoded
Content-Length: 51
test%5B1%5D=a&test%5B2%5D=b&test%5B3%5D=c&action=Go

Quelqu'un at-il une idée de pourquoi cela se produit? Je panique sur celui-ci, cela m'a déjà coûté tellement de temps ...

Mise à jour:

Nous l'avons essayé sur différents serveurs, sur les boîtes Windows, cela fonctionne, sur le serveur Ubuntu avec PHP version 5.2.4 (avec Suhosin), il ne fonctionne pas. Il fonctionne même sur un serveur différent, également avec Ubuntu et la même PHP, également avec Suhosin installé.

J'ai différencié les deux fichiers, c'est la sortie (diff php.ini phps.ini):

270c270
< memory_limit = 32M
---
> memory_limit = 16M      ; Maximum amount of memory a script may consume (16MB)
415c415
< variables_order = "EGCSP"
---
> variables_order = "EGPCS"
491d490
< include_path = ".:"
1253a1253,1254
> extension=mcrypt.so
>

Dans ce phps.ini est celui du serveur sur lequel il fonctionne et php.ini est l'actuel. On dirait qu'il n'y a pas de problème ici, non?

21
rael_kid

Il y a un certain nombre de raisons possibles pour lesquelles le tableau de messages peut être vide - il y a de fortes chances qu'il revienne à une erreur humaine/développeur. J'ai rencontré ce problème lors de la mise à niveau de PHP 5.2 vers 5.4, c'était simple mais il a fallu des heures de dépannage pour trouver le bogue. Dans notre fichier config.php, nous avions l'instruction ci-dessous pour traiter $ Tableaux _POST:

if (!get_magic_quotes_gpc()) {
    if (isset($_POST)) {
        foreach ($_POST as $key => $value) {
            $_POST[$key] =  trim(addslashes($value));
        }
    }

Les guillemets magiques étaient une fois allumés, et dans les versions PHP jusqu'à 5.2, cela a bien fonctionné, mais tout ce qui est supérieur à la version 5.2 ne sera pas traité et un tableau vide sera retourné.

Si vous n'avez pas activé error_reporting(), je vous suggère de le faire et je suis sûr que vous pourrez résoudre le problème.

Vous devez également vérifier les fonctionnalités obsolètes du système, comme "magic_quotes", Car leur utilisation ne renvoie tout simplement pas les résultats. J'espère que ça aide. Bonne chance. JCS :)

2
user1360528

Cela fonctionne-t-il sans les indices explicites? Essayer:

<form method="post" action="test.php">
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="submit" name="action" value="Go" />
</form>
2
Matthew Groves

Eu un problème assez similaire. Eh bien, tout d'abord, il m'a fallu un certain temps pour arriver à ce poste. Pour comprendre le nom de mon problème, j'ai dû installer PHP, comprendre comment l'utiliser. Déboguer le code que je ne connaissais pas. Aller à la racine du problème et toujours être perplexe.

La solution était assez simple en fait. Dans Chrome, appuyez sur F12 pour accéder aux outils de développement, sélectionnez Réseau, essayez de publier votre formulaire. Tracez la demande de post, regardez le statut. Si c'est 301 (ou autre chose que 200) - vous avez exactement le même problème que j'avais jusqu'à récemment!

Mon nouveau fournisseur d'hébergement redirigeait http://my_site.com vers http://www.my_site.com , tout ce que j'avais à faire était de modifier certains paramètres dans le cadre de mon CMS (le vôtre peut être différent mais similaire en quelque sorte) de

$Configuration['BASE_URL'] = 'http://my_site.com'

à

$Configuration['BASE_URL'] = 'http://www.my_site.com'

Et le tour est joué, la magie et les arcs-en-ciel et les licornes et mon site fonctionne enfin!

P.S. Jouer avec vos paramètres d'hébergement pourrait également résoudre votre problème ... Si votre problème est similaire au mien bien sûr ...

1
Barmaley

Il existe des rapports de bogues sur ce problème ou des problèmes similaires dans le bugtracker de PHP:

Malheureusement, il ne mentionne pas de solution, mais vous pouvez essayer de définir un autre CONTENT_TYPE ou aucun type de contenu.

1
joschi

En PHP de base, je ne peux penser qu'à une seule option de configuration qui pourrait casser cela, qui est post_max_size, vérifiez donc votre php.ini et les fichiers associés pour vous assurer que cette valeur est saine et non définie sur zéro ou sur une valeur non valide comme un caractère alphabétique.

Suhosin permet de bloquer les variables de publication dans diverses conditions, y compris des éléments tels que la longueur du tableau et la longueur du nom de variable. Grep vos fichiers php.ini pour "suhosin" pour voir si des paramètres sont présents, en particulier tout commençant par "suhosin.post". (Voir http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth pour plus de détails sur les paramètres auxquels je pense.)

Malheureusement, à moins d'une erreur majeure dans la configuration qui définit une valeur à un ou zéro, votre code (et vos variables) sont suffisamment courts pour que ce soit un peu long. Si cela ne s'affiche pas, ma prochaine suggestion serait de sauvegarder vos configurations Apache et PHP, nuke leurs répertoires, purger les packages, réinstaller et commencer à remettre les morceaux de configuration en place jusqu'à ce que le code s'arrête fonctionne à nouveau (alternativement, commencez à mettre à jour le serveur qui fonctionne avec les configurations du serveur qui ne fonctionne pas jusqu'à ce qu'ils soient tous les deux en panne). Puisque vous avez le même serveur OS-même-PHP qui fonctionne correctement, il s'agit presque certainement d'une erreur de configuration sur le serveur défectueux. quelque part, mais c'est une assez grosse botte de foin à rechercher.

Le contrôle de version de/etc est fortement recommandé avant de commencer - regardez dans le paquet etckeeper. (En fait, je recommande son utilisation, point final. Économiseur d'esprit majeur, en particulier sur une machine où plus d'une personne a un accès root.)

0
Zed

Essayez de renommer votre bouton d'envoi en autre chose que l'action. J'ai eu quelques problèmes avec cela dans le passé. Avoir une entrée nommée "action" semble être le problème.

0
wbanks

Même ce PO est assez ancien, mais aujourd'hui j'ai rencontré un problème similaire.

Après avoir passé quelques heures à vérifier des millions de choses différentes encore et encore, nous avons finalement découvert qu'après la dernière mise à jour de la version PHP 5.6.17 dans notre cPanel à PHP paramètres par défaut le http n'a pas été sélectionné. enter image description here

Et après l'avoir réglé sur sélectionné - tout revient à la normale :-)

enter image description here

J'espère que cela aidera tous les futurs lecteurs

0
Nikita Kurtin

Les éléments suivants ne devraient PAS vous aider. Il s'oppose à tout ce que je sais de la configuration PHP:

< variables_order = "EGCSP"
---
> variables_order = "EGPCS"

Celui-ci m'a sauté dessus. Vos superglobaux sont enregistrés dans différents ordres. Cela ne devrait pas poser de problème car vous n'utilisez pas register_globals et ne vous fiez pas à eux, cela ne devrait pas être un problème de changer l'ordre dans lequel les variables d'ordre sont traitées.

Mais vous devriez définitivement essayer et changer l'ordre des variables.

0
pacey

Je ne suis pas sûr mais ayant

name="test[1]"

etc. peut confondre php. Je changerais les noms d'entrée en test_1, test_2 et voir ce qui se passe.

0
haavee

Si cela peut aider quelqu'un d'autre ... Je viens de passer des heures à résoudre un problème similaire et le problème était la limite max_input_vars = "1000" de php.ini. Assurez-vous de vérifier les valeurs php.ini de upload_max_filesize, post_max_size et max_input_vars. Dépasser un entraînera un tableau $ _POST vide.

0
Chris L.

J'ai des échecs de soumission de formulaires partout depuis que j'ai mis à niveau vers Debian "testing" de "stable". Il semble qu'Apache2 ou php5 ne gère pas plusieurs éléments dans la soumission avec le même nom. Par exemple; votre formulaire a deux entrées nommées "mo". Dans le passé, une seule des valeurs de "mo" pouvait passer. Maintenant, le formulaire semble supprimer toutes les données après la première occurrence d'une clé en double. Pas encore sûr. J'essaie toujours de comprendre.

0
Robert Lance

Essayez de copier le php.ini du serveur qui fonctionne sur celui-ci (sauvegardez d'abord le php.ini du serveur qui ne fonctionne pas). Si c'est le cas, c'est quelque chose là-dedans (peut-être que le variable_order, ou peut-être la mémoire, les deux sont cependant peu probables).

0
gravyface