Tajemniczo pusta tablica $ _POST

Mam następującą stronę HTML / PHP:

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

Jak widać, formularz zostanie przesłany, a oczekiwanym wynikiem jest tablica POST z jedną tablicą zawierającą wypełnione wartości i jednym wpisem „akcja” o wartości „Go” (przycisk). Jednak bez względu na to, jakie wartości wprowadzam w polach; wynik jest zawsze:

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

W jakiś sposób tablica o nazwie test zostaje opróżniona, zmienna „action” się przedostaje.

Użyłem rozszerzenia Live HTTP Headers dla Firefoksa, aby sprawdzić, czy pola POST zostały przesłane, i robią to. Odpowiednie informacje z nagłówków Live HTTP (z a, bi wypełnionymi jako wartości w polach tekstowych):

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

Czy ktoś ma pojęcie, dlaczego tak się dzieje? Przerażam się na ten, już tyle mnie to kosztowało ...

Aktualizacja:

Próbowaliśmy tego na różnych serwerach, na Windowsach to działa, na serwerze Ubuntu z PHP w wersji 5.2.4 (z Suhosin), nie działa. Działa nawet na innym serwerze, również z Ubuntu i tą samą wersją PHP, również z zainstalowanym Suhosin.

Zróżnicowałem dwa pliki, to jest output ( 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
>

W tym phps.ini jest ten z serwera, na którym działa, a php.ini jest obecny. Wygląda na to, że nie ma tu żadnych problemów, prawda?

Czy to działa bez wyraźnych wskaźników? Próbować:

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

Istnieje wiele możliwych powodów, dla których tablica wpisów może być pusta - istnieje szansa, że ​​wróci do błędu człowieka / programisty. Dokładnie napotkałem ten problem podczas aktualizacji z PHP 5.2 do 5.4, było to proste, ale znalezienie błędu zajęło wiele godzin. W naszym pliku config.php mieliśmy poniższą instrukcję do przetwarzania tablic $ _POST:

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

Magiczne cytaty były kiedyś włączone, a w wersjach PHP do 5.2 powyższe działało dobrze, ale wszystko powyżej wersji 5.2 nie będzie przetwarzane i zostanie zwrócona pusta tablica.

Jeśli się nie error_reporting()włączyłeś, sugeruję, że tak, i jestem pewien, że będziesz w stanie rozwiązać problem.

Powinieneś także sprawdzić, czy nie ma przestarzałych funkcji systemu, takich jak „ magic_quotes”, ponieważ ich użycie po prostu nie zwraca wyników. Mam nadzieję, że to pomoże. Powodzenia. JCS :)

Istnieją raporty o błędach dotyczące tego lub podobnych problemów w programie do śledzenia błędów PHP:

• http://bugs.php.net/bug.php?id=49945
• http://bugs.php.net/bug.php?id=45043

Niestety nie wspomina o rozwiązaniu, ale możesz spróbować ustawić inny CONTENT_TYPE lub nie mieć żadnego typu zawartości.

Miał dość podobny problem. Przede wszystkim zajęło mi sporo czasu, aby dostać się do tego postu. Aby wymyślić nazwę mojego problemu, musiałem zainstalować konsolę PHP, wymyślić, jak z niej korzystać. Debuguj kod, o którym nic nie wiedziałem. Dotrzyj do sedna problemu i nadal daj się zwieść.

Rozwiązanie było dość proste. W Chrome naciśnij klawisz F12, aby przejść do narzędzi dla programistów, wybierz Sieć, spróbuj opublikować formularz. Żądanie śledzenia posta, sprawdź status. Jeśli jest 301 (lub cokolwiek innego niż 200) - masz dokładnie ten sam problem, który miałem do niedawna!

Mój nowy dostawca hosta przekierowywał http://my_site.com na http://www.my_site.com , wszystko, co musiałem zrobić, to zmienić niektóre ustawienia w ramach mojego CMS (twoje mogą być inne, ale w pewien sposób podobne) od

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

do

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

I voila, magia, tęcze, jednorożce i moja strona wreszcie działa!

PS Messing z ustawieniami hostingu może również rozwiązać problem ... Jeśli twój problem jest podobny do mojego oczywiście ...

Nie jestem pewien, ale mam

name="test[1]"

itp. mogą mylić php. Zmieniłbym nazwy wejściowe na test_1, test_2 i sprawdziłem, co się stanie.

W podstawowym PHP mogę wymyślić tylko jedną opcję konfiguracji, która mogłaby to zepsuć post_max_size, dlatego sprawdź swój plik php.ini i powiązane pliki, aby upewnić się, że ta wartość jest rozsądna, a nie ustawiona na zero lub niepoprawną wartość jak znak alfabetyczny .

Suhosin umożliwia blokowanie zmiennych post w różnych warunkach, w tym takich jak długość tablicy i długość nazwy zmiennej. Grepuj pliki php.ini dla „suhosin”, aby zobaczyć, czy są jakieś ustawienia, szczególnie wszystko zaczynające się od „suhosin.post”. (Zobacz http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth, aby uzyskać więcej informacji na temat parametrów, o których myślę.)

Niestety, z wyjątkiem poważnego błędu w konfiguracji, który ustawia pewną wartość na jeden lub zero, twój kod (i zmienne) są na tyle krótkie, że jest to coś długiego. Jeśli okaże się to puste, moją następną sugestią byłoby utworzenie kopii zapasowej konfiguracji Apache i PHP, nuke ich katalogów, wyczyszczenie pakietów, ponowna instalacja i rozpoczęcie przywracania fragmentów konfiguracji do momentu, aż kod przestanie działać (alternatywnie, zacznij aktualizować ten serwer który działa z konfiguracjami z niedziałającego serwera, dopóki oba nie zostaną uszkodzone). Ponieważ serwer PHP działający w tym samym systemie operacyjnym działa poprawnie, prawie na pewno jest to błąd konfiguracji na źle działającym serwerze, ale jest to dość duży stóg siana do przeszukania.

Przed uruchomieniem tego zaleca się kontrolę wersji / etc - zajrzyj do pakietu etckeeper. (Właściwie to zalecam jego użycie, kropka. Znaczna oszczędność poczytalności, szczególnie na komputerze, na którym więcej niż jedna osoba ma dostęp do roota.)

Wszędzie pojawiają się błędy przesyłania formularzy, ponieważ uaktualniłem do Debiana „testowanie” ze „stabilnego”. Wygląda na to, że apache2 lub php5 nie obsługuje wielu elementów o tej samej nazwie. Na przykład; twój formularz ma dwa wejścia o nazwie „mo”. W przeszłości tylko jedna z wartości „mo” przetrwała. Teraz formularz wydaje się usuwać wszystkie dane po pierwszym wystąpieniu duplikatu klucza. Nie wiem jeszcze. Wciąż próbuję to rozgryźć.

Spróbuj skopiować plik php.ini z serwera, który działa na ten (najpierw wykonaj kopię zapasową niedziałającego serwera php.ini). Jeśli tak, to coś w tym jest (może zmienna_zamówienie lub pamięć, choć mało prawdopodobne).

Spróbuj zmienić nazwę przycisku przesyłania na coś innego niż akcja. W przeszłości miałem z tym pewne problemy. Problem stanowi wejście o nazwie „akcja”.

Poniższe NIE powinny ci pomóc. Przeciwstawia się wszystkim, co wiem o konfiguracji PHP:

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

Ten skoczył na mnie. Twoje superglobale są rejestrowane w różnych zamówieniach. Nie powinno to stanowić problemu, ponieważ ponieważ nie używasz ich register_globalsi nie polegasz na nich, zmiana kolejności przetwarzania zmiennych kolejności nie powinna być problemem.

Ale zdecydowanie powinieneś spróbować i zmienić kolejność zmiennych.

Nawet ten OP jest dość stary, ale dzisiaj napotkałem podobny problem.

Po spędzeniu kilku godzin na sprawdzaniu milionów różnych rzeczy, w końcu odkryłem, że po ostatniej aktualizacji wersji PHP 5.6.17 w naszym cPanel przy domyślnych ustawieniach PHP, http nie został wybrany.

A po ustawieniu na wybrane - wszystko wraca do normy :-)

Mam nadzieję, że pomoże to przyszłym czytelnikom

Jeśli to może pomóc komukolwiek innemu ... Właśnie spędziłem godziny, aby naprawić podobny problem, a problemem był limit max_input_vars = „1000” php.ini. Pamiętaj, aby sprawdzić wartości php.ini dla upload_max_filesize, post_max_size i max_input_vars. Przekroczenie jednego spowoduje pustą tablicę $ _POST.