从 SO 上或 SilverStripe 论坛中的问题来看,我面临着一个非常普遍的情况:文件上传失败。
但是,我的情况似乎源于我尚未在网络上遇到过的问题;通过阅读其他问题和许多博客文章或论坛主题,我排除了:
- 权限问题 PHP配置中的
upload_max_filesize
和post_max_size
(均设置为8M)
Apache 配置中的 LimitRequestBody
(默认值为 0,表示“无限制”)
出于多种原因,我已经排除了这些可能性,但这张图片显示了上传有时有效的三个连续上传的示例:
我也有started a thread在 SilverStripe 论坛上解决这个问题,但我不太希望在那里幸运地解决问题。
我在Upload
、UploadField
和File
类中设置了断点,并逐步执行了数小时的代码,但仍未成功识别错误原因。
到目前为止,我的发现是任何超过 128 kiB 的文件都会导致内部服务器错误。任何低于此大小阈值的文件都会按预期上传。
发生此错误时,所有日志(Apache、PHP、SilverStripe)都完全静音。
许可问题似乎不太可能,因为:
- PHP 作为由 ISPConfig 创建的用户 (
web1
) 在 Fast-CGI 模式下运行 - Apache 以用户身份运行
apache:apache
- 我已将
apache
添加到用户组,以便groups web1
给我web1 : client1 sshusers
和groups apache
给我apache : apache ispapps ispconfig client1
- 上传文件夹 (
assets
) 归web1:client1
所有,权限为 775 - 临时上传文件夹 (
upload_tmp_dir
) 归web1:client1
所有,权限为 775。
我相信我正在寻找的是一种以某种方式获取有关上传失败的位置和原因的信息的方法。是否可以将 Apache 的日志级别设置为“调试”或“跟踪”?
注意:“类似问题”中的一个条目让我找到了 this answer ,这暗示 SSLRenegBufferSize
默认为 128 kiB。不幸的是,协议(protocol)是 HTTPS 还是 HTTP 没有影响:问题出现了。
[编辑] 我稍后将 LogLevel
指令设置为 trace
但我在服务器日志中仍然没有关于此错误的消息。
最佳答案
快速谷歌搜索将我带到了以下文章:
- Debian Jessie - Apache2 / PHP 5.6, can't upload more than 128kb
- https://wordpress.org/support/topic/cant-upload-images-larger-than-128kb-http-error
那些建议检查FcgidMaxRequestLen
设置值。
这并没有回答如何正确调试,但有助于解决原始问题。
关于php - 如何诊断在 Apache 上运行的 SilverStripe 中的文件上传失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39055389/