I hear about instances like this a lot. Did a broken request just resolve to the contents of the file that created it, or did it just spit itself out in your browser console?
The former. This was back in the days when CGI was popular and it was common for the URL path to point to the file that served the application, with the web server recognizing that it should execute the file rather than serve it. In this case the misconfigured web server didn't execute the file but rather served it up as if it were a regular file.
I ran into a site like this recently. Honestly, I think it's great because you can tell what action you need to take to resolve the error. Clear cookies? Come back later? They're actually out of business? The stack trace reveals all.
I enjoy how transparent client-side apps are these days. I remember trying to order something from an online store, and the "submit" button wouldn't work because some third-party license key wouldn't validate (I think it was to load a map to show your own address?), and that error stopped the actual sending of the HTTP request to submit an order. I patched that out and submitted my order. Easier than finding their email address and waiting a week for their contractors to fix it.