【发布时间】：2018-02-26 01:59:10
【问题描述】：
希望有一个简单的改变（或被忽略的东西）。 我们将 PHP 应用程序从 Redhat 5.9 和 PHP 5.4.14 移植到：
PHP 5.6.33 (cli) (built: Jan 14 2018 08:26:10)
Red Hat Enterprise Linux Server release 6.9 (Santiago)
在这两种情况下，都是 Apache 2.2.23
我们有一个 API，允许特定应用程序发送 POST 数据，有时还发送文件。 （我们在测试时使用 POSTMAN）。
在 Postman 中，如果我以 form-data（包括文件）的形式向“somefile.up.php”发送 POST 请求，那么我第一次在 PHP 端单击 Postman 中的“发送”时，如果我print_r 在 $_POST 和 $_FILES 数组上，我可以看到所有预期的数组键和值，包括 $_FILES。
如果我在 Postman 中发送另一个 POST 请求，并且所有详细信息都相同，则 $_FILES 数组为空（我只看到打印的 $_POST 变量）。 看起来该文件根本不存在。有时唯一可行的方法是选择不同的文件进行上传（在 Postman 中）并再次发送请求，但该文件只能发送一次。后续发送产生一个空的 $_FILES 数组。
我检查了文件（临时）发送到的位置，通常$_FILES['keyname']['tmp_name'] 的值是/tmp/php...，当文件到达时 [error] 值是 0。我还可以看到文件的名称和类型，以及它的大小。
我还检查了 post_max_size 和 upload_max_filesize 的 php.ini 值，并且 post_max_size 大了 1 M。
当应用程序在 PHP 5.4.14 和 Redhat 5.9 下运行时，我们能够多次发送相同的文件
更新：如果我使用 shell（在这种情况下为 babun）执行操作，我可以每次都正确发送文件。所以我的猜测是 Postman 内部正在发生一些事情。这解决了我大约 50% 的问题，只是因为最初接收文件的脚本必须验证其内容，然后执行 Curl 发布以将其发送到另一台服务器。尝试后，文件未到达 $_FILES 数组。
UPDATE2：通过更新代码解决了从服务器发送文件到服务器的问题。该代码在文件名前使用了非常古老的“at 符号”来获取其内容。根据建议更新代码 forget-the-at-use-curl-file-create 。因此，此时需要对 Postman Standalone 应用程序进行故障排除。
【问题讨论】：
-
也许某处有一个配置可以防止在给定时间内重复请求？只是一个想法......
-
可能是权限问题！
-
感谢@ArashKiani，但我不认为这是基于权限的。我可以从 babun shell 一次又一次地发送相同的文件，但在 Postman 中它只能工作一次，除非我删除“文件”参数并重试。