Frage Mysteriös leeres $ _POST-Array


Ich habe die folgende HTML / PHP Seite:

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

Wie Sie sehen können, wird das Formular übergeben und die erwartete Ausgabe ist ein POST-Array mit einem Array darin, das die ausgefüllten Werte und einen Eintrag "action" mit dem Wert "Go" (die Schaltfläche) enthält. Egal, welche Werte ich in die Felder eingebe; Das Ergebnis ist immer:

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

Irgendwie wird das Array namens test geleert, die Variable "action" schafft es durch.

Ich habe die Live-HTTP-Header-Erweiterung für Firefox verwendet, um zu prüfen, ob die POST-Felder gesendet werden, und das tun sie auch. Die relevanten Informationen von Live-HTTP-Headern (mit a, b und c, die als Werte in die Textfelder eingegeben wurden):

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

Hat jemand eine Idee, warum das passiert? Ich flippe hier aus, es hat mich schon so viel Zeit gekostet ...

Aktualisieren:

Wir haben das auf verschiedenen Servern versucht, auf Windows-Boxen funktioniert es, auf dem Ubuntu-Server mit PHP Version 5.2.4 (mit Suhosin) tut es das nicht. Es funktioniert sogar auf einem anderen Server, auch mit Ubuntu und der gleichen PHP-Version, auch mit Suhosin installiert.

Ich habe die zwei Dateien, das ist die Ausgabe (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
>

In dieser phps.ini ist derjenige von dem Server, auf dem es funktioniert und php.ini ist der aktuelle. Sieht so aus, als ob es hier keine Probleme gäbe, oder?


20
2018-03-30 11:19


Ursprung


Suhosin kann sein. - Col. Shrapnel
Ya, Suhosin klingt wie ein wahrscheinlicher Kandidat - SeanJA
Könntest du noch mehr Infos geben? Suhosin ist auf dem Server installiert, sollte ich es ausschalten? Sollte ich Einstellungen ändern? - rael_kid
Versuchen Sie es, es wird protokolliert, wenn es sich um ein Sihosin-Problem handelt. gehärtete-php.net/suhosin/configuration.html#suhosin.simulation
Ich habe versucht, den Simulationsmodus einzuschalten. Das Array ist noch leer. Ich kann die Log-Dateien jedoch nicht finden ... - rael_kid


Antworten:


Es gibt eine Reihe von möglichen Gründen, warum das Post-Array leer sein könnte - es besteht die Möglichkeit, dass es zu einem menschlichen / Entwickler-Fehler kommt. Ich habe genau dieses Problem beim Upgrade von PHP 5.2 auf 5.4 erlebt, es war einfach, aber es dauerte Stunden der Fehlersuche, um den Fehler zu finden. In unserer config.php-Datei hatten wir die folgende Anweisung, um $ _POST-Arrays zu verarbeiten:

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

Magic Quotes war einmal an, und in PHP-Versionen bis 5.2 funktionierte das obige gut, aber irgendetwas über Version 5.2 wird es nicht verarbeiten und ein leeres Array wird zurückgegeben.

Wenn Sie nicht haben error_reporting() Ich schlage vor, dass Sie das tun und ich bin mir sicher, dass Sie das Problem beheben können.

Sie sollten auch nach veralteten Systemfunktionen suchen, z. B. "magic_quotes"Wenn ich sie verwende, kann ich einfach keine Ergebnisse zurückgeben. Ich hoffe, das hilft. Viel Glück. JCS :)


2
2018-05-06 08:01





Funktioniert es ohne die expliziten Indizes? Versuchen:

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

1
2018-03-30 11:51



Nein, funktioniert auch nicht. - rael_kid
Setzen Sie die Indizes für das Test-Array nicht - sie machen die POST-Variablenerkennung durcheinander - adam
Okay, ich kann sie weglassen. Aber es löst mein Problem nicht. - rael_kid


Es gibt Fehlerberichte zu diesem oder ähnlichen Problemen im PHP-Bugtracker:

Leider wird hier keine Lösung erwähnt, aber Sie könnten versuchen, einen anderen Inhaltstyp CONTENT_TYPE oder überhaupt keinen Inhaltstyp festzulegen.


1
2018-03-31 06:16



Diese Fehler sind ähnlich, aber nicht die gleichen wie meine. Ich habe versucht, den Inhaltstyp zu setzen (wie Sie im Codeausschnitt in meiner ursprünglichen Antwort sehen können). Wenn ich überhaupt keinen Inhaltstyp einstelle funktioniert es auch nicht ... - rael_kid


Hatte ein ziemlich ähnliches Problem. Nun, zuerst brauchte ich eine ganze Weile, um zu diesem Posten zu kommen. Um den Namen meines Problems herauszufinden, musste ich die PHP-Konsole installieren, um herauszufinden, wie man sie benutzt. Debuggen Sie den Code, von dem ich nichts wusste. Gehen Sie zur Wurzel des Problems und seien Sie immer noch verwirrt.

Die Lösung war eigentlich ziemlich einfach. In Chrome drücken Sie F12, um zu den Entwicklertools zu gelangen, wählen Sie Netzwerk, versuchen Sie, Ihr Formular zu posten. Verfolgen Sie die Post-Anfrage, sehen Sie sich den Status an. Wenn es 301 (oder etwas anderes als 200) ist - haben Sie genau das gleiche Problem, das ich bis vor kurzem hatte!

Mein neuer Host-Provider hat umgeleitet http://meine_site.com zu http://www.meine_site.comAlles, was ich tun musste, ist einige Einstellungen als Teil meines CMS zu ändern (Ihr könnte anders sein, aber in gewisser Weise ähnlich)

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

zu

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

Und voila, die Magie und die Regenbogen und die Einhörner und meine Seite funktioniert endlich!

P.S. Das Problem mit Ihren Hosting-Einstellungen kann auch Ihr Problem lösen ... Wenn Ihr Problem mir natürlich ähnlich ist ...


1
2017-11-15 22:16



Verdammt. Umleitung war auch mein Problem! - Aman Alam


Ich bin mir nicht sicher aber

name="test[1]"

usw. kann PHP verwirren. Ich würde die Eingabenamen in test_1, test_2 ändern und sehen, was passiert.


0
2018-03-30 11:23



@haavee: Nein, PHP wirbt diese Verwendung: php.net/manual/en/faq.html.php#faq.html.arrays - Boldewyn
Ich habe das versucht, auf diese Weise funktionieren die Variablen, aber sie sind nicht in einem Array. - rael_kid
@haavee: Nein, die Notation verwechselt PHP nicht, es ist Standard Verwendung von PHP + -Formularen. Siehe Boldewyns Link. :)
OK danke! habe heute etwas Neues gelernt.
@adam: "Es ist auch möglich, Ihren Arrays bestimmte Schlüssel zuzuweisen".


Im Basis-PHP kann ich mir nur eine Konfigurationsoption vorstellen, die das kaputt machen könnte post_max_sizeÜberprüfen Sie daher Ihre php.ini und verwandte Dateien, um sicherzustellen, dass dieser Wert normal ist und nicht auf Null oder einen ungültigen Wert wie ein alphabetisches Zeichen gesetzt ist.

Suhosin ermöglicht das Blockieren von Post-Variablen unter verschiedenen Bedingungen, einschließlich der Array-Länge und der Variablennamenlänge. Überzeuge deine php.ini-Dateien von 'suhosin', um zu sehen, ob irgendwelche Einstellungen vorhanden sind, insbesondere alles, was mit 'suhosin.post' beginnt. (Sehen http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth für mehr Details zu den Parametern, an die ich denke.)

Leider gibt es einen großen Fehler in der Konfiguration, der einen Wert auf eins oder null setzt. Ihr Code (und die Variablen) sind also kurz genug, dass dies eine lange Geschichte ist. Wenn das leer ist, wäre mein nächster Vorschlag, Ihre Apache- und PHP-Konfigurationen zu sichern, ihre Verzeichnisse zu säubern, die Pakete zu bereinigen, neu zu installieren und Config-Chunks wieder einzufügen, bis der Code nicht mehr funktioniert (alternativ, starten Sie diesen Server zu aktualisieren) das funktioniert mit Konfigurationen vom nicht funktionierenden Server, bis beide kaputt sind. Da der selbe-OS-selbe-PHP-Server korrekt funktioniert, ist dies fast sicher ein Konfigurationsfehler auf dem fehlerhaften Server, aber das ist ein ziemlich großer Heuhaufen zum Durchforsten.

Die Versionskontrolle von / etc wird dringend empfohlen, bevor Sie damit beginnen - sehen Sie sich das Etckeeper-Paket an. (Eigentlich empfehle ich seine Verwendung, Punkt. Major Sanity Saver, insbesondere auf einer Maschine, wo mehr als eine Person Root-Zugang hat.)


0
2018-04-02 14:46



Meine post_max_size ist 8M, ich denke, das wäre genug. Meine php.ini enthält keine Einträge mit Suhosin, das könnte ein Problem sein ... Hat Suhosin eigene Conf-Files? - rael_kid
Nicht standardmäßig, aber die Einstellungen für jedes PHP-Modul können von jeder Datei in /etc/php5/conf.d auf einem Debian-System gesetzt werden, und daher nehme ich auch ein Ubuntu-System an. Wie ich schon sagte, das war eine lange Geschichte. Trotzdem würde ich zunächst jede Konfigurationsdatei mit einem funktionierenden System vergleichen. - Zed


Seit meinem Upgrade auf Debian "testing" von "stable" habe ich Fehler bei der Formularübertragung. Es scheint, dass apache2 oder php5 nicht mehrere Objekte in der Einreichung mit dem gleichen Namen behandeln. Zum Beispiel; Ihr Formular hat zwei Eingaben namens "mo". In der Vergangenheit würde nur einer der Werte für "mo" durchkommen. Jetzt scheint das Formular alle Daten nach dem ersten Auftreten eines doppelten Schlüssels fallen zu lassen. Noch nicht sicher. Ich versuche immer noch, es herauszufinden.


0
2018-04-09 17:26





Versuchen Sie, die php.ini von dem Server zu kopieren, der auf diesen Server funktioniert (sichern Sie zuerst die php.ini des nicht arbeitenden Servers). Wenn dies der Fall ist, ist es etwas darin (vielleicht die Variablen_Ordnung oder möglicherweise Speicher, beide unwahrscheinlich).


0
2018-04-09 17:39