Apache adds data to output of javascript file-CodePudding

The weirdest thing, two of my javascript files have stopped being served due to incorrect mime type from apache. All my JS files have text/javascript, but two of them get application/octet-stream.

When troubleshooting I noticed that when I connect to the web server, it outputs "31c2" before the content of the file (see image). This is not an invisible character in the actual file, verified by hexdump. I am assuming that this is the source of the incorrect mime type reporting, but where does this come from? I noticed that after the file is output, apache also adds "0" on a single line.

How do I figure out what causes this? I might add that this file was last edited in 2017 and has worked flawlessly until today or yesterday, and I can't understand why.

Here are two requests side by side to a working .js file (left) and the one that reports incorrect mime type (right). There is no .htaccess file in any parent directory either.

CodePudding user response：

Those things such as 31c2 that you see are hex encoded numbers. Now, if we decode 31c2, we get 12738. These strings only appear when you are using HTTP/1.1. Not when you are using HTTP/0.9, HTTP/1.0, HTTP/2.0, etc.

Why do these 'HEX' encoded numbers appear?

This occurs because HTTP/1.1 uses chunked transfer-encoding. Hence, you can see the header: Transfer-Encoding: chunked.

Chunked transfer-encoding has these hex strings:

CRLF a CRLF

Keep in mind that: CR = \r (carriage return), LF = \n (new line).

Now, for example, if you want to send Hello, World! to the user:

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 uses chunked transfer-encoding to send chunks as they are ready to be sent. Instead of sending all the data at once. This is especially useful for huge file transfers, where, with chunked transfer, the server doesn't need to calculate the size of the response in advance, saves time (this is also what causes the total-download size to be sometimes invisible when you are downloading stuff from some websites).

Why is your JS file not being detected as JavaScript?

It may be a bug in Apache. You should probably add this to your .htaccess/apache2.conf/httpd.conf to solve this issue:

AddType text/javascript js