should recovery middleware write a error page?

polaris · · 412 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<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=""></a></p> <p>[2] <a href=""></a></p> <p>[3] <a href=""></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>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

412 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传