should recovery middleware write a error page?

<p>I took a look at a few big frameworks and I noticed that recovery middleware only writes 500 instead of writing a error page. </p> <p>For example gogs uses the macaron framework [1]. The macaron recovery handler only writes the header with a 500 status code [2]. Or gin [3]</p> <p>Initially I thought that an error page would make more sense, as there is some actual html for clients to know something went wrong. But even gogs only writes a 500, no error page. I&#39;m not so sure anymore.</p> <p>[1] <a href="https://github.com/gogits/gogs/blob/master/cmd/web.go#L106">https://github.com/gogits/gogs/blob/master/cmd/web.go#L106</a></p> <p>[2] <a href="https://github.com/go-macaron/macaron/blob/master/recovery.go#L154">https://github.com/go-macaron/macaron/blob/master/recovery.go#L154</a></p> <p>[3] <a href="https://github.com/gin-gonic/gin/blob/develop/recovery.go#L42">https://github.com/gin-gonic/gin/blob/develop/recovery.go#L42</a></p> <p>edit: to clarify I mean a page that says something like &#34;something went wrong, but don&#39;t worry, the monkeys are on the case&#34; in some nice typography.</p> <hr/>**评论：**<br/><br/>mwholt: <pre><p>You shouldn&#39;t write error details out to the error page -- unless, by &#34;error page&#34; you simply mean a custom page that looks nice, rather than plaintext &#34;Internal server error&#34;... error details can sometimes contain sensitive information that makes it easier for attackers to exploit your system.</p> <p>Anyway, in Caddy how we handle this is we log the error (and/or stack trace, if applicable) to the error log. This is not public and allows the website owner to get the full details of the error. Caddy can serve a custom error page that looks pretty, or if you don&#39;t set one, it writes a simple, generic plaintext error message.</p> <p>The exception is if you specifically turn on error details in the response; in this case, Caddy will write out the error details to the error page -- this is useful in local testing/dev situations when you don&#39;t want to keep looking at your log, and you just want to see the error when you load the page. However, as I said, this is a bad idea in production.</p> <p>To answer your question: Yes, I prefer that web apps write error pages that look nice, but they shouldn&#39;t contain error details.</p></pre>nhooyr: <pre><p>of course I didn&#39;t mean write the stack trace or any error details at all to the client. Just a nice simple generic page.</p></pre>daveddev: <pre><p>A panic should be an indication of an exceptional problem. Log the issue and send out the most basic of messages in a sure-fire way.</p> <p>Otherwise, if something occurs like an err returned from json.Marshal(), I have a helper function which logs the issue and prints an HTML version of the basic error message.</p></pre>Akkifokkusu: <pre><p>Remember, not every web server is used to serve user-facing content, and not every web server is used to serve HTML. It would be strange for a JSON API to spit out HTML in the case of an error. The plaintext that results from only writing a header isn&#39;t a lot better, though. I haven&#39;t looked at the specific cases you&#39;re talking about, but it would make sense to be able to define what content is sent.</p></pre>mvpmvh: <pre><p>This</p></pre>