[英]How do I debug broken response headers in Apache?
We're trying to get Webdav running in Kubernetes using an Azure Files storage backend, which is mounted in the container on /dav/data
.我们正在尝试使用 Azure 文件存储后端让 Webdav 在 Kubernetes 中运行,该后端安装在/dav/data
上的容器中。 The container itself is running Alpine Linux 3.12.1, in which we're installing all our required Apache packages.容器本身正在运行 Alpine Linux 3.12.1,我们正在其中安装所有必需的 Apache 包。
All is well and good when not mounting this storage, or when using a different storage backend.当不安装此存储或使用不同的存储后端时,一切都很好。 However, when mounting the Azure Files storage, stuff starts to break.但是,当安装 Azure 文件存储时,东西开始损坏。
Uploading files works without issue, but downloading does not;上传文件没有问题,但下载没有; most software complains about invalid HTTP headers/responses.大多数软件抱怨无效的 HTTP 标头/响应。 When investigating this further, I see that the beginning of the headers seems to be getting cut off.在进一步调查时,我发现标题的开头似乎被切断了。
Example headers of a correct response (obtained by not mounting the volume):正确响应的示例标头(通过未安装卷获得):
HTTP/1.1 200 OK
Date: Tue, 01 Dec 2020 13:54:53 GMT
Server: Apache/2.4.46 (Unix)
Last-Modified: Tue, 01 Dec 2020 13:51:02 GMT
ETag: "bla"
Accept-Ranges: bytes
Content-Length: 985
Connection: close
Example headers of an incorrect response:错误响应的示例标头:
s: bytes
Content-Length: 985
Connection: close
Everything up to the first s
in the Accept-Ranges
header seems to be getting eaten somewhere. Accept-Ranges
header 中第一个s
之前的所有内容似乎都在某个地方被吃掉了。 There also seem to be a number of extra null bytes at the end of the response.响应末尾似乎还有许多额外的 null 字节。
In an effort to get to the bottom of this I looked into logging as much as I possibly could, and stumbled upon the DumpIO module, which would allow me to log both the response headers as well as the body.为了深入了解这一点,我尽可能多地研究了日志记录,并偶然发现了 DumpIO 模块,它允许我记录响应标头和正文。 For some reason, loading this module, setting DumpIOOutput On
and LogLevel dumpio:trace7
actually fixes the issue.出于某种原因,加载这个模块,设置DumpIOOutput On
和LogLevel dumpio:trace7
实际上解决了这个问题。 Response headers are fine, and the response body is exactly what you'd expect.响应标头很好,响应正文正是您所期望的。 And it's driving me nuts.它让我发疯。
I suspect there's some kind of weird buffer/window issue being caused by an interaction between Apache and the mounted volume, but I haven't been able to figure out what.我怀疑 Apache 和安装的卷之间的交互会导致某种奇怪的缓冲区/窗口问题,但我无法弄清楚是什么。
We've since changed the storage backend used for the volume, but I'd still really like to know what caused this issue.我们已经更改了用于卷的存储后端,但我仍然很想知道是什么导致了这个问题。
I've also been able to reproduce this locally in Docker.我还能够在 Docker 中本地重现此内容。
Having the exact same issue after upgrading the AKS cluster from 1.17 to 1.18.将 AKS 群集从 1.17 升级到 1.18 后出现完全相同的问题。 Headers are malformed.标头格式不正确。 Tried updating to a newer Apache version but doesn't work.尝试更新到较新的 Apache 版本,但不起作用。 Temporarily switched from azureFile
to azureDisk
and that works!暂时从azureFile
切换到azureDisk
并且有效! Will see if I can create an AKS bug report for this看看我是否可以为此创建 AKS 错误报告
In case you haven't come across the culprit yet (or anyone else coming across this while googling like I did).万一你还没有遇到罪魁祸首(或者像我一样在谷歌搜索时遇到这个问题的人)。 The issue is Apache's EnableMMAP setting.问题是 Apache 的 EnableMMAP 设置。
Solution: In your Apache conf, set EnableMMAP off
.解决方案:在您的 Apache conf 中,设置EnableMMAP off
。
Sources:资料来源:
https://cloudiseasy.com/2021/06/13/deploying-apache-server-on-aks-with-azure-files/ https://cloudiseasy.com/2021/06/13/deploying-apache-server-on-aks-with-azure-files/
https://httpd.apache.org/docs/2.4/mod/core.html#enablemmap https://httpd.apache.org/docs/2.4/mod/core.html#enablemmap
Apache is adding header to images resulting in corrupting images Apache 正在将 header 添加到图像中,从而导致图像损坏
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.