Expand my Community achievements bar.

SOLVED

Change HTTP status code for HTML page served in CQ 5.5

Avatar

Level 1

I'm trying to support a CQ5 (5.5) installation developed by an outside firm for my company.

It appears that my company wanted a pretty 404 page that looked like the rest of the site, and using the custom Sling 404.jsp error handler to redirect to a regular page that merely says "Page Not Found" was the easiest way to do it. The problem is that the "Page Not Found" page they are using actually returns a 200 status code since it really is just a regular content page that bears a "Not Found" message on it.

This is causing us problems with Google and the GoogleBot, since Google believes all the old search links to now non-existent pages are still valid (200 status code).

Is there any way to configure CQ to return the appropriate 404 status code for our regular "not found" HTML page that we display? When I am in the CQ Author mode editing the page, I find nothing in page properties or in components that could be added to the page.

Any help would be appreciated, as CQ is not exactly my area of expertise.

I'd like to note that I tried posting this in the CQ5 section, but that it is now read only.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Alright, thank you for the clarification

Yes, status does not carry over during redirects.

No, adding a static 404 status into a 'regular page' is not the best way to go, as every regular page will get hard coded 404 status.

What might work:

  1. Add new checkbox into your dialog.xml file for that particular 'regular page' template.
  2. Add custom code into your jsp to check value of the checkbox
  3. When checkbox is ticked set status to 404

Againg this would not be perfect as content authors might mistakenly click that checkbox and mark 'regular page' as 404.

Therefore, it would be better to create error page template that would have configurable status in page properties, which would be then propogated to the page. This would prevent content authors from making mistakes.

Thanks,

Peter

View solution in original post

5 Replies

Avatar

Community Advisor

Hello Michael,

Welcome to the forums :)

The solution will depend on the complexity of your 404 page. Is it a static page with no authentication required or dynamic page that changes based on client state?

Good way to configure 404's and 500's is at Dispatcher(apache2) level without even touching Sling layer *1

This would allow you to:

a) Remove load from publishers

b) Provide 500 page whenever the actual Publisher is down.

That is, it would be better to serve from apache2 then serving them from the sling layer IF it's a simple static page.

Alternatively, you can add following line to your custom 404.jsp error page to make dynamic page report 404 status:

<% slingResponse.setStatus(404); %> *2

 *1 Link: http://www.wemblog.com/2013/03/how-to-cache-error-page-in-cq.html

*2 Link: https://sling.apache.org/documentation/the-sling-engine/errorhandling.html

Thanks,

Peter

Avatar

Level 1

If I'm clear on what you are saying, you suggest either I take the 404 page completely out of CQ5 or that I set the status code in 404.jsp.

A static page solution is not viable since they want the Page Not Found page to be totally integrated into the site, including all menus.

The 404.jsp solution doesn't sound like it will work either unless somehow setting that slingResponse.setStatus(404) call carries across redirects, which I really can't see happening since the redirect itself uses a 302 response code to get to that page.

The issue is that we already have a custom 404.jsp handler, and it handles 404s by redirecting to a regular page that simply displays "not found".  Unless you are suggesting that I can put a bit of JSP code into that regular "not found" page to set the status code, then I don't think this addresses my question.

Thanks.

PuzanovsP wrote...

Hello Michael,

Welcome to the forums :)

The solution will depend on the complexity of your 404 page. Is it a static page with no authentication required or dynamic page that changes based on client state?

Good way to configure 404's and 500's is at Dispatcher(apache2) level without even touching Sling layer *1

This would allow you to:

a) Remove load from publishers

b) Provide 500 page whenever the actual Publisher is down.

That is, it would be better to serve from apache2 then serving them from the sling layer IF it's a simple static page.

Alternatively, you can add following line to your custom 404.jsp error page to make dynamic page report 404 status:

  1. <% slingResponse.setStatus(404); %> *2

 *1 Link: http://www.wemblog.com/2013/03/how-to-cache-error-page-in-cq.html

*2 Link: https://sling.apache.org/documentation/the-sling-engine/errorhandling.html

Thanks,

Peter

 

Avatar

Correct answer by
Community Advisor

Alright, thank you for the clarification

Yes, status does not carry over during redirects.

No, adding a static 404 status into a 'regular page' is not the best way to go, as every regular page will get hard coded 404 status.

What might work:

  1. Add new checkbox into your dialog.xml file for that particular 'regular page' template.
  2. Add custom code into your jsp to check value of the checkbox
  3. When checkbox is ticked set status to 404

Againg this would not be perfect as content authors might mistakenly click that checkbox and mark 'regular page' as 404.

Therefore, it would be better to create error page template that would have configurable status in page properties, which would be then propogated to the page. This would prevent content authors from making mistakes.

Thanks,

Peter

Avatar

Level 1

OK, that makes some sense.  I'll look into that and see if it is something we can work with.

Avatar

Level 1

While I liked your idea for marking a page as returning a 404 and configuring the JSP to support that, I went with a simpler solution based upon a suggestion from StackOverflow.com.  Basically, instead of redirecting to the "pretty" page not found page, I am including it in the custom 404.jsp handler.

I appreciate the help, though.