[MAGNOLIA-389] 404 page doesn't send back 404 HTTP status code Created: 13/May/05  Updated: 05/Nov/12  Resolved: 16/Aug/05

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.01
Fix Version/s: 2.1 Final

Type: Bug Priority: Major
Reporter: Andreas Weder Assignee: Sameer Charles
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

any


Attachments: Text File MAGNOLIA-389-rev1093.patch     Text File MAGNOLIA-389.patch     Text File MAGNOLIA-389.patch     PNG File MAGNOLIA-389.png    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

If magnolia is asked to serve a page, which doesn't exist, it returns the configured 404 page instead ("Server"/"ResourceNotAvailableURI"). It doesn't sent back a 404 HTTP status code, however. The result of this is that e.g. search engines cache the page as regular page since there is it is an error page.

This is particular nasty if you relaunch a website and have to deal with old URLs you'd like to just eventually disappear from everybodys bookmarks and all engines.



 Comments   
Comment by Boris Kraft [ 21/May/05 ]

see also http://jira.magnolia.info/browse/MAGNOLIA-84

Comment by Andreas Brenk [ 24/May/05 ]

The attached patch fixes this issue.

I changed sendRedirect(String) calls to sendError(int) and implemented an ErrorServlet that can also serve as the basis for a fix to issue MAGNOLIA-84 (it just needs to load more error-page mappings than just the 404 one).

Comment by Andreas Weder [ 26/May/05 ]

Thanks, Andreas. I'm using the 2.02 branch, but I could port the patch.

I wonder what would be the best for this to be incorporated into the official code. Provide exemplary error pages and link them instead of the ErrorServlet you're using, maybe?

Comment by Andreas Brenk [ 26/May/05 ]

In my opinion the best would be the following:

  • Drop all usage of sendRedirect() for error messages as it always sets the HTTP status to 302 (temporary redirection).
  • Only use sendRedirect() for redirections, setStatus() for 2xx and 3xx, sendError() for 4xx and 5xx.
  • Incorporate my patch and extend it for more error codes (the whole 4xx and 5xx range).
  • Map the ErrorServlet for that codes in web.xml.
  • Create a content node "errorPages" in the "server" config folder with error-page mappings as node data (like in web.xml).
  • Bootstrap these nodes with default mappings to pages in admindocroot (or similar).
  • Create these default error pages so they resemble the container ones (perhaps copy the Tomcat ones).

This way the default behaviour wouldn't really change (The default error pages would like somewhat different, but that's it.) and the mappings could be easily customized.

I'd be happy to do this. It's a nice way to get up to speed with Magnolia development.

Comment by Andreas Weder [ 26/May/05 ]

Yes, this sounds like a very good proposal. I also like that you intend to use the AdminGUI to configure pages.

I'd be willing to make a backport of your changes to 2.02. I'd certainly be interested, since I do have 2.02 webs to maintain and they lack this feature. As a matter of fact, statistics seem to suggest that engines keep hitting the "ResourceNotAvailable" page quite often, thus I'd like to see real HTTP status codes being sent back to the clients.

Comment by Andreas Brenk [ 26/May/05 ]

I updated the patch to read multiple error-page mappings from the repository and created a simple 404 default. The mapping is automatically reloaded with each change. No need to restart the context.

You have to create an "errorPages" contentNode in config/server (see the attached screenshot).

Comment by Andreas Weder [ 31/May/05 ]

Thanks for the patch. I've tried to quickly apply it to the 2.02 code. It turns out it will need a little bit more work than that, thus I can't do it right now. I'm going to ask for some time to work on that.

Comment by Andreas Brenk [ 23/Jun/05 ]

Andreas, now that you've got commit rights I'd really like to work something up to get this integrated. Did you succeed in backporting the patch to 2.0.2?

In my opinion returning wrong status codes is a major issue that should be fixed for 2.1. I'd need some assistence to get the error-page mappings into the repository bootstrap process but otherwise the patch should be fairly complete.

Comment by Andreas Brenk [ 23/Jun/05 ]

I've updated the patch to apply cleanly to revision 1093.

Comment by Andreas Weder [ 03/Jul/05 ]

Andreas, thanks a lot for updating the patch. Sorry for the late reply.

I'll check your patch as soon as possible. I cannot currently check in anything due to an internal server problem of SVN. It seems others see this, too.
It could be then that I only manage to apply the patch after my vacation (end of July). Meanwhile I'll have to ask you to be patient.

Thanks again for the backport. This will solve one outstanding key issue of our current production environments.

Comment by Andreas Weder [ 03/Jul/05 ]

Sameer, the enclosed patch is for 2.1 and solves two issues:

  • in case a page is not found or an internal server error occurs, Magnolia currently
    shows one standard error page. However, no HTTP error code is returned to the
    client.
    This leads to major problems e.g. with search engines, but also with prepended
    proxies (e.g. for caching reasons).
  • the J2EE standard defines a way to map HTTP error codes to pages.

The patch solves both issues. It allows the URI of a page to be configured in
admin central. Additional error codes may be easily added.

I haven't fully reviewed the patch. As I'm not working with 2.1 yet, I'm not sure
of its implications and I don't know how to make sure that the bootstrapping
mechanism creates the necessary nodes for a 404 and a 500 error page.

Thus I'm handing the torch back to you. I consider this patch a
candidate for 2.1 final. It would also be one needed step to later take caching
out of Magnolia and e.g. into a prepended Squid proxy.

Comment by Sameer Charles [ 03/Jul/05 ]

Thanks Andreas
ll make sure it will be implemented in 2.1

>>
I have a same problem as you, I am in US for long time and cannot work with svn anymore after svn server upgrade.
but this patch is with me now so ll update somehow.

Comment by Sameer Charles [ 03/Aug/05 ]

Andreas,

Your patch does not contain ErrorServlet, could you please attach that.

One question though : I liked the idea of configuring error pages in magnolia config tree, but what's the benefit if we anyways
have to configure again in web.xml, why dont we simply use web.xml error mappings instead of sending them to ErrorServlet
which does the same?

Comment by Sameer Charles [ 05/Aug/05 ]

I updated current trunk such that it uses default container error page handling and magnolia returns proper error code instead of temporary redirect codes

Generated at Mon Feb 12 03:16:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.