should recovery middleware write a error page?

polaris · 2016-03-30 14:35:05 · 901 次点击    
这是一个分享于 2016-03-30 14:35:05 的资源,其中的信息可能已经有所发展或是发生改变。

I took a look at a few big frameworks and I noticed that recovery middleware only writes 500 instead of writing a error page.

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]

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'm not so sure anymore.

[1] https://github.com/gogits/gogs/blob/master/cmd/web.go#L106

[2] https://github.com/go-macaron/macaron/blob/master/recovery.go#L154

[3] https://github.com/gin-gonic/gin/blob/develop/recovery.go#L42

edit: to clarify I mean a page that says something like "something went wrong, but don't worry, the monkeys are on the case" in some nice typography.


评论:

mwholt:

You shouldn't write error details out to the error page -- unless, by "error page" you simply mean a custom page that looks nice, rather than plaintext "Internal server error"... error details can sometimes contain sensitive information that makes it easier for attackers to exploit your system.

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't set one, it writes a simple, generic plaintext error message.

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'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.

To answer your question: Yes, I prefer that web apps write error pages that look nice, but they shouldn't contain error details.

nhooyr:

of course I didn't mean write the stack trace or any error details at all to the client. Just a nice simple generic page.

daveddev:

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.

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.

Akkifokkusu:

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't a lot better, though. I haven't looked at the specific cases you're talking about, but it would make sense to be able to define what content is sent.

mvpmvh:

This


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

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