php $ _POST dizisi form gönderildiğinde boş


100

Geliştirme kutumda (Ubuntu / PHP5 + / MySQL5 +) mükemmel şekilde çalışan, oluşturduğum özel bir CMS'im var.

Onu müşterimin üretim kutusuna taşıdım ve şimdi tüm form gönderimleri boş $ _POST dizileri olarak görünüyor.

Verilerin gerçekte kullanılarak geçirildiğini doğrulamak için bir hile buldum file_get_contents('php://input');ve veriler orada iyi görünüyor - $_POST/ $_REQUESTdizileri her zaman boş.

Ayrıca, içerik türü başlıklarının doğru olduğunu firebug ( application/x-www-form-urlencoded; charset=utf-8) aracılığıyla da doğruladım .

Bu sorun, bir formun AJAX aracılığıyla mı yoksa normal bir form gönderimi yoluyla mı gönderildiğine bakılmaksızın gerçekleşir.

Herhangi bir yardım büyük beğeni topluyor!

php  arrays  forms  post 

Post_max_size kontrol edin: değer 8MB değil 8M olarak ayarlanmalıdır. Son durumda, herhangi bir hata görmeyeceksiniz, ancak $ _POST boyutu 0 olarak ayarlanacak
Sergei Karpov

1
Dikkat: Eğik çizgi eksikse Apache bir 301 yönlendirmesi yapar.
Leandro

Yanıtlar:


190

Bu sorunun bir Form aracılığıyla POST ile ilgili olduğunu biliyorum, ancak buraya JSON içerik türü ile POST yaparken benzer sorunların yanıtlarını aramaya geldim. Cevabı buldum ve bana çok zamana mal olduğu için paylaşmak istedim.

JSON içerik türünü kullanırken $ _POST dizisi doldurulmayacak (yalnızca inandığım çok parçalı formlarla)

Sorunu düzeltmek için ne işe yaradı:

$rest_json = file_get_contents("php://input");
$_POST = json_decode($rest_json, true);

umarım bu birine yardımcı olur!


1
Bu geçici çözüm mantıklı - toplu güncelleme denetleyicimi düzeltti :)
Martin Zeitler

2
Başka bir alternatif, Content-Typebaşlığı olarak değiştirmek application/x-www-form-urlencodedve ardından verilerinizi ile serileştirmektir $.param(dataObject). Bu yardımcı olmalı.
ŁukaszBachman

1
@ ŁukaszBachman DataObject ........ gibi bir şey ise bunu nasıl title=something&body=anything. Unvan ve gövde vadesini almak istiyorum. $ dataobject ["başlık"] boş döndürür. Benim durumumda $ _POST boş. Ve file_get_contents ("php: // input") kullanarak elde etmenin tek yolu ... json olarak kodlanmamış olması dışında.
Hurşid Alam

Bu çok kullanışlıdır. İşin garibi, Json'u geliştirme makineme göndermekle ilgili bir sorun yaşamıyorum, ancak üretim makinesine yapıyorum.
Simon H


88

İşte başka bir olası neden - formum WWW olmadan domain.com'a gönderiliyordu. ve "WWW" yi eklemek için otomatik bir yeniden yönlendirme kurmuştum. $ _POST dizisi bu süreçte boşalıyordu. Bu yüzden düzeltmek için tek yapmam gereken www.domain.com adresine göndermekti


25
Kahretsin, postadaki bir url yeniden yazımı htaccessPOST'lerin çalışmamasının nedeniydi. Tüm url'lere otomatik olarak eğik çizgi ekliyordum, ancak kodda ACTION olarak eğik çizgisiz bir url kullanıyordum. Htaccess'i kontrol etmeyi hiç düşünmediğim için cevabınız yardımcı oldu. +1
binar

Godaddy kullanarak alan adı yönlendirme (maskeleme ile) vardı ve sorunun kaynağı bu gibi görünüyor.
Chris Prince

1
Benim de benzer bir sorun yaşadım, dosyamdan geliyordu .htaccess. .phpUzantıyı URL'den çıkarıyordu ve formum uzantıya POSTsahip URL'ye gidiyordu.
Emanuel Vintilă

25

Benzer bir problemim vardı. Basit bir düzeltme olduğu ortaya çıktı. Sahip olduğum formda

<form action = "directory" method = "post">

burada dizin ... dizinin adıdır. POST dizim tamamen boştu. Tarayıcımda url'ye baktığımda, sonunda bir eğik çizgi ile görüntülendi.

Eylemimin sonuna eğik çizgi eklemek hile yaptı -

<form action = "directory /" method = "post">

$ _POST dizim yine doldu!


1
Bu bir düzeltme olmamalıdır, örneğin iyi bir yönlendirme sistemine sahip olan CakePHP'de başarısız olmuştur (Cake'in başarısız olduğunu kastetmiyorum), belki bu soruna yaklaşım çerçeve veya .php dosyaları değildir, ancak apache üzerinde biraz yapılandırma, bu sorunla ilgili daha fazla araştırma yapmak istiyorum. Oldukça ilginç.
James

Benzer bir kayda göre, OP ile aynı sorunu yaşadım, ancak yalnızca <form>etiketin bir nameözniteliği yoksa ve yalnızca IE'de.
jkt123

14

Php.ini içinde şunlardan emin olun:

  • track_vars (yalnızca çok eski PHP sürümlerinde mevcuttur) olarak ayarlanmıştır On
  • variables_order mektubu içerir P
  • post_max_size makul bir değere ayarlanmıştır (örneğin, 8 MB)
  • (suhosin yaması kullanılıyorsa) suhosin.post.max_varsve suhosin.request.max_varsyeterince büyük.

Sanırım ikinci önerim sorununuzu çözecektir.


1
Teşekkürler MrMage, anlayışınız için teşekkür ederiz ve bu ini ayarlarını kontrol edip hile yapıp yapmadığını size bildireceğiz. Teşekkürler!

1
"post_max_size" ayarı benim göstericimdir. Form gönderme sırasında büyük bir dosya yüklüyordum ve bu ayar daha az değer içeriyordu. Bu yüzden formu gönderdiğimde boş bir yazı dizisi alıyorum.
shasi kanth

9

HTTP'den HTTPS'ye gönderirken $_POSTboş olduğunu buldum . Bu, formu test ederken oldu, ancak bunu anlayana kadar biraz zaman aldı.


5

Benzer ancak biraz farklı bir sorunla karşılaştım ve sorunu anlamak 2 gün sürdü.

  • Benim durumumda POST dizisi de boştu.

  • Daha sonra file_get_contents ('php: // input'); ve o da boştu.

Daha sonra, POST gönderiminden sonra yüklenen sayfayı yenilersem, tarayıcının form verilerini yeniden göndermek için onay istemediğini fark ettim. Doğrudan sayfayı yeniliyordu. Ancak form URL'sini farklı bir URL ile değiştirdiğimde, POST'u düzgün bir şekilde geçiriyordu ve sayfayı yenilemeye çalışıldığında verileri yeniden göndermeyi istedi.

Sonra gerçek URL'de neyin yanlış olduğunu kontrol ettim. URL ile ilgili bir hata yoktu, ancak URL'de index.php bulunmayan bir klasöre işaret ediyordu ve ben index.php'de POST'u kontrol ediyordum.

Burada /index.php'den / dizinine yönlendirmenin POST verilerinin kaybolmasına ve URL'ye index.php ekleyerek URL'nin test edilmesine neden olduğundan şüphe ettim.

İşe yaradı.

Birinin yararlı bulması için buraya gönderdim.


1
Aynı sorunu yaşadım, url'nin sonunda '/' olmadan, $ _REQUEST'te hiçbir şey yok, ancak '/' veya '/index.php' ile, gönderilen tüm veriler $ _REQUEST'te var. Nginx ayarlarım veya başka bir şey olabilir!
MohaMad

5

Having enable_post_data_readingayarı devre dışı bu neden olacaktır. Belgelere göre:

enable_post_data_reading

Bu seçeneğin devre dışı bırakılması $ _POST ve $ _FILES dosyalarının doldurulmamasına neden olur. Sonradan veriyi okumanın tek yolu php: // girdi akışı sarmalayıcısıdır. Bu, istekleri proxy yapmak veya POST verilerini bellek açısından verimli bir şekilde işlemek için yararlı olabilir.


5

Örneğin /api/index.php gibi bir dizindeki bir index.php dosyasına gönderim yapıyorsanız, formunuzda dosyanın tam dizini belirttiğinizden emin olun, örn.

Bu

<form method="post" action="/api/index.php"> 
</form>

VEYA

<form method="post" action="/api/"> 
</form>

İşler.

Ama bu başarısız

<form method="post" action="/api"> 
</form>

Aslında tam tersine sahibim. Bunun /my_uriişe yarayacağını keşfettim ama işe yaramadı /my_uri/.
Link14

1
aynı sorunu yaşadı. apache veya nginx, / api'den / api / konumuna bir yönlendirme ekliyor gibi görünüyor
John Smith

Eğik çizgi eksikse Apache otomatik bir yeniden yönlendirme 301 yapar. Cevabınız için teşekkürler ve yorumlarınız da faydalıdır.
Leandro

4

Şu anda zarif bir çözümünüz yok ama bu sorunla karşılaşan diğerlerinin ileride başvurması için bulgularımı paylaşmak istedim. Sorunun kaynağı, .htaccess dosyasında 2 php değerinin geçersiz kılınmasıydı. Dosya yüklemeleri için dosya yükleme sınırını varsayılan 8MB'den daha büyük bir şeye yükseltmek için bu 2 değeri basitçe ekledim - htaccess dosyasında bu 2 değeri varsayılandan daha büyük veya daha küçük olmanın soruna neden olduğunu gözlemledim. .

php_value post_max_size xxMB
php_value upload_max_filesize xxMB

Tüm suhosin.post.xxx/suhosin.upload.xxx değişkenlerinin sınırlarını yükseltmek için ek değişkenler ekledim ancak maalesef bunların bu soruna bir etkisi olmadı.

Özetle, burada gerçekten "neden" i açıklayamıyorum, ancak temel nedeni belirledim. Benim hissim şu ki, bu sonuçta bir suhosin / htaccess sorunu, ancak maalesef yukarıdaki 2 php geçersiz kılınan değerleri kaldırmak dışında çözemediğim bir sorun.

Umarım bu, bunu çözmek için birkaç saatimi öldürdüğümde gelecekte birine yardımcı olur. Bana bu konuda yardım etmek için zaman ayıran herkese teşekkürler (MrMage, Andrew)


Bu soruyu Serverfault üzerinde sormaya değer olabilir, özellikle de sorun sunucu kurulumu / htaccess ile ilgiliyse.
David,

5
Yanılmıyorsam, boyut "xxM" gibi belirtilmelidir, "xxMB" değil, bu yüzden bununla bir ilgisi olabilir mi diye merak ediyorum ...
JC Inacio,

4

Varsayılan "metin / düz" olduğundan, enctype = "application / x-www-form-urlencoded" kullanarak sorunu çözebilirim. $ DATA'yı iade ettiğinizde, ayırıcı "metin / düz" için bir boşluk ve "urlencoded" için özel bir karakterdir.

Saygılarımızla Frank


4
<form action="test.php" method="post">
                        ^^^^^^^^^^^^^

Tamam, bu aptalcaydı ve toplum içinde kendimi utandıracağım, ancak PHP'deki bir şey için küçük bir test komut dosyası hazırladım ve $_POSTdizim boşken, ilk baktığım yer StackOverflow'du ve ihtiyacım olan cevabı bulamadım .

Sadece yazdım

<form action="test.php">

ve yöntemi olarak belirtmeyi unutmuş POST!

Eminim ki birisi kısılır, ama bu aynı şeyi yapan başka birine yardım ederse, o zaman umrumda değil! Hepimiz zaman zaman yapıyoruz!


bunu da unuttuğuma inanamıyorum! Sadece yeni bir sunucu deniyorum ve bunun konfigürasyondan kaynaklandığını düşündüm ... her neyse, hatırlatma için teşekkürler!
Samuel Aiala Ferreira

4

Benim durumumda, HTTP'den HTTPS'ye gönderirken, $ _POST boş geliyor. Sorun, formun //example.com gibi bir eylemi olmasıydı. URL'yi https://example.com olarak düzelttiğimde sorun ortadan kalktı.


1
Sanırım sunucunun nasıl kurulduğuyla ilgili bir şey. GoDaddy'yi sunucu olarak kullanırken aynı sorunları yaşıyorum. Bu çözüm sorunu çözmedi.
acarlstein

Bu çözüm sorunumu çözdü. Güzel bir başlığım vardı.
gokaysatir

3

burada aynı sorun!

postacıda posta isteği yoluyla yerel sunucu koduma bağlanmaya çalışıyordum ve bu sorun zamanımı boşa harcadı!

yerel proje kullanan herkes için (örneğin postacı): "localhost" anahtar sözcüğü yerine IPv4 adresinizi kullanın (cmd olarak ipconfig yazın). benim durumumda:

önce:

localhost/app/login

sonra:

192.168.1.101/app/login

Postacı bana tırnak işaretleri veya boşluklar içeren kazınmış json değerleriyle ilgili birkaç sorun verdi. Belirli bir format bekliyor.
Tom Anderson

2

REFERANS: http://www.openjs.com/articles/ajax_xmlhttp_using_post.php

POST yöntemi

POST yöntemi istek gönderilirken kullanılsın diye bazı değişiklikler yapacağız ...

var url = "get_data.php";
var params = "lorem=ipsum&name=binny";
http.open("POST", url, true);

//Send the proper header information along with the request
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http.setRequestHeader("Content-length", params.length);
http.setRequestHeader("Connection", "close");

http.onreadystatechange = function() {//Call a function when the state changes.
  if(http.readyState == 4 && http.status == 200) {
    alert(http.responseText);
  }
}
http.send(params);

Bazı http başlıkları herhangi bir POST isteğiyle birlikte ayarlanmalıdır. Bu yüzden onları bu satırlara yerleştirdik ...

http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http.setRequestHeader("Content-length", params.length);
http.setRequestHeader("Connection", "close");

Yukarıdaki satırlarla temel olarak veri gönderiminin bir form gönderimi biçiminde olduğunu söylüyoruz. Ayrıca gönderdiğimiz parametrelerin uzunluğunu da veriyoruz.

http.onreadystatechange = function() {//Call a function when the state changes.
  if(http.readyState == 4 && http.status == 200) {
    alert(http.responseText);
  }
}

'Hazır durum' değiştirme olayı için bir işleyici belirledik. Bu, GET yöntemi için kullandığımız aynı işleyicidir. Http.responseText'i burada kullanabilirsiniz - innerHTML (AHAH) kullanarak bir div içine ekleyin, değerlendirin (JSON) veya başka herhangi bir şey.

http.send(params);

Son olarak istek ile birlikte parametreleri gönderiyoruz. Verilen url ancak bu satır çağrıldıktan sonra yüklenir. GET yönteminde, parametre boş bir değer olacaktır. Ancak POST yönteminde, gönderilecek veriler, gönderme işlevinin bağımsız değişkeni olarak gönderilecektir. Params değişkeni ikinci satırda lorem=ipsum&name=binny- bu nedenle sırasıyla 'ipsum' ve 'binny' değerleriyle iki parametre gönderiyoruz - 'lorem' ve 'name' olarak bildirildi.


2

Bunun eski olduğunu biliyorum ama çözümümü paylaşmak istedim.

Benim durumumda, PHP'nin maksimum yükleme sınırını yükseltmek için değişkenler eklerken sorun .htaccess'imde oldu. Kodum şöyleydi:

php_value post_max_size 50MB
php_value upload_max_filesize 50MB

Daha sonra değerlerin xxM'yi değil xxMB'yi sevmesi gerektiğini ve bunu şu şekilde değiştirdiğimde fark ettim:

php_value post_max_size 50M
php_value upload_max_filesize 50M

şimdi $ _POST'um verileri daha önce normal şekilde döndürdü. Umarım bu gelecekte birine yardımcı olur.


1

Benim durumumda, formu göndermek için jQuery'yi kullanmadan hemen önce sayfadaki tüm girişleri devre dışı bırakmak için jQuery kullanıyor olmamdı. Bu yüzden, "gizli" türleri bile her girişi devre dışı bırakmamı değiştirdim:

$(":input").attr("disabled","disabled"); 

"yalnızca 'düğme' türü girişleri devre dışı bırakmak" için:

$('input[type=button]').attr('disabled',true);

Bu, kullanıcının yanlışlıkla 'git' düğmesine iki kez basmaması ve DB'mizi hortumlamaması için yapıldı! Görünüşe göre, "devre dışı bırakılmış" özniteliğini "gizli" bir tür form girişine koyarsanız, form gönderildiğinde değerleri gönderilmeyecektir!


1

Benim için .htaccess, mod_rewrite kurulu olmadığında yeniden yönlendiriyordu. Mod_rewite'i kurun ve her şey yolunda.

Özellikle:

<IfModule !mod_rewrite.c>
  ErrorDocument 404 /index.php
</Ifmodule>

yürütüyordu.


1

Benzer bir sorunu çözmek için saatler harcadım. Benim durumumdaki sorun şuydu:

max_input_vars = "1000"

varsayılan olarak php.ini içinde. Yüklemesiz gerçekten büyük bir formum vardı. php.ini, upload_max_filesize = "100M" ve post_max_size = "108M" olarak ayarlandı ve benim durumumdaki sorun kesinlikle bu değildi. PHP davranışı, formda 1000 değişkeni aştığında max_input_vars için aynıdır. _POST dizisini döndürür ve boşaltır. Keşke bunu bir saat önce bulabilseydim.


0

MRMage'in gönderisine ek olarak:

Bu değişkeni, bazı $_POSTdeğişkenlerin (büyük bir dizi> 1000 öğe ile) ortadan kalktığı sorununu çözmek için ayarlamam gerekiyordu :

suhosin.request.max_vars = 2500

" request" değil " post" çözümdü ...


0

Belki de en uygun çözüm değil, ancak form actionözniteliğini kök etki alanına ayarlarsam index.php'ye erişilebileceğini ve gönderilen değişkenleri alabileceğini anladım . Ancak yeniden yazılmış bir URL'yi eylem olarak ayarlarsam çalışmaz.


0

Bu @icesar ne tür benzer taşımaktadır söyledi .

Ancak, içinde bulunan API'ime bir şeyler göndermeye çalışıyordum site/api/index.php, sadece kendiliğinden site/apigeçtiği için gönderiyordum index.php. Ancak bu, görünüşe göre $_POST, anında boşaldığım için bir şeylerin karışmasına neden oluyor . site/api/index.phpBunun yerine doğrudan adresine göndermek sorunu çözdü.


0

Benim sorunum, <base>test sitemin temel URL'sini değiştirmek için HTML etiketini kullanmamdı . Bu etiketi başlıktan çıkardıktan sonra $_POSTveriler geri geldi.


0

Benim durumumda (OVH mutualisé sunucusundaki php sayfası) enctype="text/plain"çalışmıyor ( $_POSTve karşılık gelen $_REQUESTboş), aşağıdaki diğer örnekler çalışıyor. '

<form action="?" method="post">
<!-- in this case, my google chrome 45.0.2454.101 uses -->
<!--     Content-Type:application/x-www-form-urlencoded -->
    <input name="say" value="Hi">
    <button>Send my greetings</button>
</form>

<form action="?" method="post" enctype="application/x-www-form-urlencoded">
    <input name="say" value="Hi">
    <button>Send my application/x-www-form-urlencoded greetings</button>
</form>

<form action="?" method="post"  enctype="multipart/form-data">
    <input name="say" value="Hi">
    <button>Send my multipart/form-data greetings</button>
</form>

<form action="?" method="post" enctype="text/plain"><!-- not working -->
    <input name="say" value="Hi">
    <button>Send my text/plain greetings</button>
</form>

'

Daha fazlası burada: method = "post" enctype = "text / plain" uyumlu değil mi?


0

Mod Security'den şu hatayı alıyordum:

Access denied with code 500 (phase 2). Pattern match "((select|grant|delete|insert|drop|alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|UNION SELECT.*\'.*\'.*,[0-9].*INTO.*FROM)" at REQUEST_BODY. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "345"] [id "300013"] [rev "1"] [msg "Generic SQL injection protection"] [severity "CRITICAL"]

Mod güvenlik yapılandırmamı test etmek için kaldırdıktan sonra, beklendiği gibi çalıştı. Şimdi, güvenli ama ihtiyaçlarıma göre yeterince esnek kalmak için kurallarımı değiştirmem gerekiyor :)


0

Giriş etiketinde name = " your_variable_name " kullandığınızdan emin olun .

Yanlışlıkla id = " your_variable_name " kullanıyorum.

Böceği yakalamak için çok zaman harcadım.


0

nameHer alanın özelliğinin tanımlandığından emin olun .

Bu size PHP'de boş bir POST oluşturur

<input type="text" id="Phone">

Ama bu işe yarayacak

<input type="text" name="Phone" id="Phone">

Sanırım sunucunun nasıl kurulduğuyla ilgili bir şey. GoDaddy'yi sunucu olarak kullanırken aynı sorunları yaşıyorum. Bu çözüm sorunu çözmedi.
acarlstein

Önem verenler için, kendi kabusuna gitmen gerekebilir .htaccess.
acarlstein

-1

Tamam, davamı buraya koymam gerektiğini düşündüm .... Post dizisini belirli durumlarda boş alıyordum .. Form iyi çalışıyor, ancak bazen kullanıcılar gönder düğmesine bastıklarından şikayet ediyor ve hiçbir şey olmuyor ... Bir süre kazı yaptıktan sonra, barındırma şirketimin, kullanıcıların girişlerini kontrol eden ve bulursa tüm post dizisini (yalnızca kötü amaçlı verileri değil) temizleyen bir güvenlik modülüne sahip olduğunu keşfettim. Örneğimde, bir matematik öğretmeni denklemi girmeye çalışıyordu: dy + dx + 0 = 0; ve veriler tamamen silindi.

Bunu düzeltmek için, şimdi metin alanına dy + dx + 0 = sıfır olarak veriyi girmesini tavsiye ediyorum ve şimdi işe yarıyor ... Bu birisine biraz zaman kazandırabilir ..


5
Kullanıcılardan hatalı kod için ödenek ayırmalarını istemek başlangıç ​​değildir.
freeworlder

Bu gerçekten hatalı bir kod değil, ancak yeni bir barındırma sağlayıcısı düşünebilirsiniz. Alternatif olarak, girişi farklı bir biçimde gönderin, örneğin HTML URL kodlaması.
Tom Anderson
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.