There are several scripts that do the following when they want to signal that a resource (usually a MARC record) does not exist: print $query->redirect("/cgi-bin/koha/errors/404.pl"); This is not great, because what actually happens is that an HTTP 302 redirect is issued, followed by the 404. This wastes a bit of time for the user agent, and might be problematic if you let search engines crawl your OPAC. Better would be doing print $cgi->header( -status => '404 record not found'); or if a more specific message should be displayed, constructing it and calling output_with_http_headers $query, $cookie, $error_template->output, 'html', '404 Not Found'; The affected scripts are: catalogue/showmarc.pl opac/opac-ISBDdetail.pl opac/opac-MARCdetail.pl opac/opac-authoritiesdetail.pl opac/opac-detail.pl opac/opac-export.pl opac/opac-showmarc.pl opac/opac-topissues.pl opac/tracklinks.pl
Indeed. I think there should be HTML static pages for all HTTP error codes. They should be used in both apache configuration and in GCI output (maybe adding methods into C4::Output).
With Bug 30261, we should be able to use C4::Output::output_error() for any staff interface or OPAC page.
(In reply to Fridolin Somers from comment #1) > Indeed. > I think there should be HTML static pages for all HTTP error codes. > They should be used in both apache configuration and in GCI output (maybe > adding methods into C4::Output). I like the idea of static HTML pages. I think we've avoided them because we want to use the templating and such for a common look and feel, but I was just thinking... we could generate the static HTML pages during an app build step. I suppose that wouldn't work well for a git deployment though...