Apache 将数据添加到 javascript 文件的输出
Apache adds data to output of javascript file
最奇怪的是，由于 apache 的 mime 类型不正确，我的两个 javascript 文件已停止提供服务。我所有的 JS 文件都有 text/javascript，但其中两个文件有 application/octet-stream.
在进行故障排除时，我注意到当我连接到网络服务器时，它在文件内容之前输出“31c2”（见图）。这不是实际文件中的不可见字符，已通过 hexdump 验证。我假设这是不正确的 MIME 类型报告的来源，但这从何而来？我注意到文件输出后，apache还在一行中添加了“0”。
我如何找出造成这种情况的原因？我可能会补充一点，这个文件最后一次编辑是在 2017 年，直到今天或昨天都可以正常工作，我不明白为什么。
这里有两个对工作 .js 文件的并排请求（左）和一个报告错误 MIME 类型的请求（右）。任何父目录中也没有 .htaccess 文件。
您看到的 31c2 之类的东西是十六进制编码的数字。现在，如果我们解码 31c2，我们会得到 12738。这些字符串仅在您使用 HTTP/1.1 时出现。当您使用 HTTP/0.9、HTTP/1.0、HTTP/2.0 等
时则不会
为什么会出现这些 'HEX' 编码的数字？
这是因为 HTTP/1.1 使用分块 transfer-encoding。因此，你可以看到 header: Transfer-Encoding: chunked.
Chunked transfer-encoding 有这些十六进制字符串：
CRLF a CRLF
请记住：CR = \r（回车 return），LF = \n（换行）。
现在，例如，如果你想发送 Hello, World! 给用户：
HTTP/1.1 200 OK
[CRLF]
Connection: Keep-Alive
[CRLF]
Transfer-Encoding: chunked
[CRLF]
[CRLF] # END OF HEADERS: the first hex won't contain another CRLF, idk why they chose to do this
5 # 5 in hex, is 5
[CRLF]
Hello
[CRLF] # first CRLF of hex
8 # 8 in hex, is 8
[CRLF] # second CRLF of hex
, World!
[CRLF] # first CRLF of hex encoding
0 # means this is the end of the transfer
[CRLF] # second CRLF of hex encoding
[CRLF] # contains third CRLF for the end too
HTTP/1.1 使用 chunked transfer-encoding 发送块，因为它们已准备好发送。而不是一次发送所有数据。这对于大文件传输特别有用，其中，通过分块传输，服务器不需要提前计算响应的大小，节省时间（这也是导致 total-download 大小有时不可见的原因当您从某些网站下载内容时）。
为什么你的 JS 文件没有被检测为 JavaScript？
这可能是 Apache 中的错误。您可能应该将此添加到您的 .htaccess/apache2.conf/httpd.conf 以解决此问题：
AddType text/javascript js
最奇怪的是，由于 apache 的 mime 类型不正确，我的两个 javascript 文件已停止提供服务。我所有的 JS 文件都有 text/javascript，但其中两个文件有 application/octet-stream.
在进行故障排除时，我注意到当我连接到网络服务器时，它在文件内容之前输出“31c2”（见图）。这不是实际文件中的不可见字符，已通过 hexdump 验证。我假设这是不正确的 MIME 类型报告的来源，但这从何而来？我注意到文件输出后，apache还在一行中添加了“0”。
我如何找出造成这种情况的原因？我可能会补充一点，这个文件最后一次编辑是在 2017 年，直到今天或昨天都可以正常工作，我不明白为什么。
这里有两个对工作 .js 文件的并排请求（左）和一个报告错误 MIME 类型的请求（右）。任何父目录中也没有 .htaccess 文件。
您看到的 31c2 之类的东西是十六进制编码的数字。现在，如果我们解码 31c2，我们会得到 12738。这些字符串仅在您使用 HTTP/1.1 时出现。当您使用 HTTP/0.9、HTTP/1.0、HTTP/2.0 等
为什么会出现这些 'HEX' 编码的数字？
这是因为 HTTP/1.1 使用分块 transfer-encoding。因此，你可以看到 header: Transfer-Encoding: chunked.
Chunked transfer-encoding 有这些十六进制字符串：
CRLF a CRLF
请记住：CR = \r（回车 return），LF = \n（换行）。
现在，例如，如果你想发送 Hello, World! 给用户：
HTTP/1.1 200 OK
[CRLF]
Connection: Keep-Alive
[CRLF]
Transfer-Encoding: chunked
[CRLF]
[CRLF] # END OF HEADERS: the first hex won't contain another CRLF, idk why they chose to do this
5 # 5 in hex, is 5
[CRLF]
Hello
[CRLF] # first CRLF of hex
8 # 8 in hex, is 8
[CRLF] # second CRLF of hex
, World!
[CRLF] # first CRLF of hex encoding
0 # means this is the end of the transfer
[CRLF] # second CRLF of hex encoding
[CRLF] # contains third CRLF for the end too
HTTP/1.1 使用 chunked transfer-encoding 发送块，因为它们已准备好发送。而不是一次发送所有数据。这对于大文件传输特别有用，其中，通过分块传输，服务器不需要提前计算响应的大小，节省时间（这也是导致 total-download 大小有时不可见的原因当您从某些网站下载内容时）。
为什么你的 JS 文件没有被检测为 JavaScript？
这可能是 Apache 中的错误。您可能应该将此添加到您的 .htaccess/apache2.conf/httpd.conf 以解决此问题：
AddType text/javascript js