表单 GET 有效，表单 POST 无效
我有一个简单的表单，当 method="GET" 时，其行为符合预期，但当 method="POST" 时，则不然。
格式：
<form action="/login" method="POST">
<input type="text" name="user" maxlength="30" value="">
<input type="password" name="pass" maxlength="30" value="">
<input type="hidden" name="sublogin" value="1">
<input type="submit" value="Login" />
</form>
如果我将变量回显到屏幕（var_dump( $_POST ) 或 var_dump( $_GET )），当 method="POST" 时，我会得到一个空数组。当 method="GET" 时，我得到一个具有适当名称/值对的数组（用户、通行证、子登录...）
要知道的事情：
- .htaccess 处理文件名（操作）的 .php，它还将所有内容重定向到索引.php 如果该文件实际上不存在。
- 网站上的其他表单可以很好地使用 POST
- 表单在我的本地计算机上可以正常工作
- 时显示 302 临时移动
Firebug 在使用按请求添加的 POST .htaccess 文件
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .$ index.php
：感谢任何帮助！
I have a simple form that behaves as expected when method="GET", but when method="POST", it does not.
FORM:
<form action="/login" method="POST">
<input type="text" name="user" maxlength="30" value="">
<input type="password" name="pass" maxlength="30" value="">
<input type="hidden" name="sublogin" value="1">
<input type="submit" value="Login" />
</form>
If I echo the variables to the screen (var_dump( $_POST ) or var_dump( $_GET )), when method="POST", I get an empty array. When method="GET" I get an array with the appropriate name/value pairs (user, pass, sublogin...)
Things to know:
- .htaccess handles the .php of the filename (action), it also redirects everything to index.php if the file does not physically exist.
- other forms on the site work just fine with POST
- the form works fine on my local machine
- Firebug shows 302 Temporarily Moved when using POST
.htaccess file added per request:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .$ index.php
Any help is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果“/login”不存在，并且 htaccess 重定向（不重写 url），则所有 POST 数据都会丢失。 GET 数据会被保留，因为它们是 URL 的一部分。
If "/login" doesn't exist, and htaccess redirects (not re-writes the url) then all POST data are lost. GET data are preserved because they're part of the URL.
这个问题根本不符合我的思路。
设置在处理后破坏 $_POST 数组的类行为不当，但无论如何都在破坏我的 $_POST 数组。仅发生在 PHP 5.3 的机器上（警告导致类行为不当），服务器运行的是 5.2。
谢谢你，布里迪斯试图提供帮助。抱歉，我让你白费力气了！
当然，解决方案是编写一种更好的方法来处理该类中的警告，并且不允许 $_POST 数组被破坏。
The problem wasn't even close to my line of thought.
A class that sets destroys the $_POST array after processing was misbehaving, but was destroying my $_POST array anyway. Only happens on machines with PHP 5.3 (a warning was causing the class to misbehave), server was running 5.2.
Thank you, Briedis for trying to help. Sorry I led you on a goose chase!
The solution, of course, was to write a better way of handling warnings in that class and not allowing the $_POST array to get destroyed.
这是一个边缘案例答案，可能有利于未来研究该主题的用户。
就我而言，解决方案是修复我在本地 php.ini 文件中创建的错误配置。为了在开发工作期间运行 Imagick 图像处理脚本，我将设置更改为更加自由。
为了将 max_post_size 从默认值 8M 增加，我将设置更改为 40。问题是缺乏明确说明“40”所指的单位。当未指定时，php.ini 使用 BYTES 作为单位。我将“M”单位后缀添加到“40”，$_POST 操作开始按预期工作。
为了将来参考，单位后缀可以是“K”、“M”或“G”，当然不带引号，或者对于字节，不带引号。您可以在 PHP 手册中阅读有关这些单元的信息：
https://secure.php.net/manual/en/faq.using.php#faq.using.shorthandbytes
This is an edge case answer that may benefit a future user researching this topic.
In my case the solution was to fix a mis-configuration I had created in my local php.ini file. I had changed my settings to be more liberal for the sake of running Imagick image processing scripts during development work.
In an attempt to increase the max_post_size from its default value of 8M, I had changed the setting to 40. The problem was the lack of explicitly stating the units that "40" referred to. When not specified, php.ini uses BYTES as the units. I added the "M" unit suffix to "40" and $_POST actions began working as expected.
For future reference, the unit suffixes can be either "K", "M", or "G", without the quotes of course, or, for bytes, absent. You can read about these units in the PHP Manual here:
https://secure.php.net/manual/en/faq.using.php#faq.using.shorthandbytes