Ticket Navigation

Ticket #283 (defect)

Opened 3 years ago

Last modified 3 years ago

Support Localized/Custom HTTP error messages.

Status: closed (invalid)

Reported by:	anonymous	Assigned to:	mikerobi
Priority:	normal	Milestone:	2.2-beta
Component:	CherryPy code	Keywords:
Cc:

Currently, http errors result in english messages based on the messages built into the python HTTP Server. It would be nice to return localized messages based on the browser's Accept-Language or the server configuration.

It would also be nice if the errors supported basic conditional expressions based on the server configuration. This would allow error pages to contain links back to the refering page, or administrator contact issue.

Change History

09/06/05 12:13:17: Modified by mikerobi

owner changed from rdelon to mikerobi.
status changed from new to assigned.

09/06/05 15:22:29: Modified by mikerobi

I have come up with a very basic, that only supports conditional substitutions.

Sample template

<h2>404 Not Found</h2>
<p>
  No file could be found at <a href="$request_path">$request_path</a>
</p>
#if referer
  <p>
   You may wish to contact the webmaster of <a href="$referer">$referer</a> and ask them to update their site.
</p>
#elif foobar
<p>$foobar$</p>
#else
<p>___</p>
#endif
<p>

If blocks can not be nested and #if/elif/else/endif, must come at the beginning of the line.

10/03/05 02:12:14: Modified by fumanchu

_cputil.getErrorPage can receive arbitrary keyword-args, which will be interpolated into the template (which is also overridable). However, HTTPError doesn't yet support sending such arguments.

10/14/05 04:15:08: Modified by mdt@emdete.de

this does not really solve the problem. also other content then text/html is requested for (see ticket 340). for now i do a cherrypy._cputil._HTTPErrorTemplate = '... which is somehow ugly. would be nice to include this in config to have different pages/mimetypes by path which would also resolve 340.

12/30/05 07:03:23: Modified by lawouach

status changed from assigned to closed.
resolution set to invalid.

I assume that if someone wants to spend time on changing the language of an error sent by its CP application, he would also spend time changing the overall layout to integrate it to its application.

Therefore externalising the default template doesn't look like the right approach to me. In fact one can totally do what one wants already by implementing specific _cp_on_error and _cp_on_http_error handlers. Those are flexible enough to change CP error handling behavior.

Maybe the book should provide more examples about it though.

I think we should close this issue as invalid.