前几天看到一个问题,提问者希望在程序中对用户进行认证后如果用户权限不够则将HttpStatusCode设置为401,并且返回自定义内容。类似的问题还看到过某些网站中需要通过URL中的某些参数获取对应的实体(如商品、用户)的信息,如果对应的实体不存在则置HttpStatus为404,并返回相应的错误页。
这些要求如果通过编程设置HttpStatusCode并在Web.config的CustomErrors中设置对应的自定义错误页可能无法直接实现。编程设置HttpStatusCode,也就是
只是将当前响应的HTTP头部的Status设置为401(404),并不对输出内容做任何修改。由于它不是真正的HTTP异常,而是正常的应用程序逻辑,所以也不会显示Web.config中设置的CustomErrors,看似CustomErrors变得无效了。
对于此类问题,我个人觉得比较好的方法还是直接进行页面跳转到提示页或直接显示对应的提示,不要修改HttpStatus。HttpStatus是用来表示HTTP状态的,并不是用来表示业务逻辑状态的。虽然可以通过在EndRequest事件中对当前响应的HttpStatus进行检查,强制输出CustomErrors中对应HttpStatus时跳转页的内容,以实现既改HttpStatus,又显示CustomErrors中的跳转页,但这样的做法我个人认为破坏了HttpStatus原来的用途,增加了应用程序与Http协议的耦合度,所以不推荐。
这些要求如果通过编程设置HttpStatusCode并在Web.config的CustomErrors中设置对应的自定义错误页可能无法直接实现。编程设置HttpStatusCode,也就是
Response.StatusCode = 401; // 或404
只是将当前响应的HTTP头部的Status设置为401(404),并不对输出内容做任何修改。由于它不是真正的HTTP异常,而是正常的应用程序逻辑,所以也不会显示Web.config中设置的CustomErrors,看似CustomErrors变得无效了。
对于此类问题,我个人觉得比较好的方法还是直接进行页面跳转到提示页或直接显示对应的提示,不要修改HttpStatus。HttpStatus是用来表示HTTP状态的,并不是用来表示业务逻辑状态的。虽然可以通过在EndRequest事件中对当前响应的HttpStatus进行检查,强制输出CustomErrors中对应HttpStatus时跳转页的内容,以实现既改HttpStatus,又显示CustomErrors中的跳转页,但这样的做法我个人认为破坏了HttpStatus原来的用途,增加了应用程序与Http协议的耦合度,所以不推荐。