User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36

Steps to reproduce:

Serve the http response body
<?php echo "Hello World";?>
with Content-Type: text/plain; charset=utf-8

Netcat server:
printf "HTTP/1.0 200 OK\r\nContent-Type: text/plain; charset=UTF-8\r\nConnection: close\r\nContent-Length: 27\r\n\r\n<?php echo 'Hello World';?>" | nc -l 9999

Actual results:

The page is treated as Content-Type: Application/octet-stream

Expected results:

Should render it as text (same as Chrome/Edge does)

sorry forgot the type in the netcat sample, fixed:
printf "HTTP/1.0 200 OK\r\nContent-Type: text/x-php; charset=UTF-8\r\nConnection: close\r\nContent-Length: 27\r\n\r\n<?php echo 'Hello World';?>" | nc -l 9999

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Looks like we might want to add text/x-php to the mime list?

(In reply to Kershaw Chang [:kershaw] from comment #3)

Looks like we might want to add text/x-php to the mime list?

I think it's more complicated than this, but either way this is basically a specific case of bug 196078. Fixing the PHP case specifically doesn't seem like it's worth the trouble, also given there's probably people who want their .php files saved to disk or opened with an editor etc.