Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

AEMaaCS - Error Handling using the acs-aem-commons package

evancooperman-rp
Level 2
Level 2

Hi everyone,

I'm wondering if anyone has run into the Adobe 500 error page (aka error page of death), even when the ACS Commons error handler is enabled in AEM as a Cloud Service.  According to the docs on the ACS Commons page - see table of incompatible ACS Commons items on https://adobe-consulting-services.github.io/acs-aem-commons/pages/compatibility.html#aem-as-a-cloud-... - error handling should work properly in AEMaaCS.  Additionally, it's working for us for 404s.  However, unfortunately, if one of our components throws a 500 error, we get the Adobe error page instead of our custom error page.  Obviously we should be catching these errors, but we want to make sure that we're serving client-specific error pages if anything unexpected happens. Here's what the Adobe 500 error page looks like, which seems to supersede the ACS Commons handling of 500 errors:

Screen Shot 2021-10-26 at 4.45.46 PM.png

I'm just wondering why it's not possible to redirect these 500 errors to our error page.  According to Experience League documentation, the recommendation is to create handlers - see https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/ful... The problem is that this doesn't allow us to have custom authored error pages, and is not desirable.

Has anyone run into this, and figured out how to get it to work properly?

 

Thanks in advance!

Evan

1 Accepted Solution
evancooperman-rp
Correct answer by
Level 2
Level 2

In working with the Adobe support team, it seems I'm not the only one having these issues with AEMaaCS.  There is a ticket in the engineering backlog to deal with it, and not much we can do for now.  There's only 1 way I've found I can skirt the Adobe error page, which is to move error handling from AEM to Apache, by changing

DispatcherPassError    0

to

DispatcherPassError    1

 and then adding ErrorDocument lines for each http status code we want to handle, and the associated page we want to handle it with.  This is much less ideal than using ACS Commons since an author has no control over which errors go to which pages, but at least it allows us to render a custom error page rather than showing end-users the Adobe error page.

That being said, this alone does not work.  Just doing this, the Adobe error page persists.  The only way to actually get the system to render your custom error page for 500 errors, for example, is to use a 301 or 302 redirect from the path you set, to a different page.  This interrupts the dispatcher rewrite processing, and then actually sends the user to your page rather than the Adobe error page.  For example we have a rewrite rule that strips .html from the end of our URLs, and adds a "/".  So, when I set up my ErrorDocument, I intentionally use the non-rewritten URL of /errors.html, which will then hit my rewrite rules and get 301 redirected to /errors/

In this way I was able to short-circuit the cloud dispatcher logic (that is out of my control) and actually send the user to our custom error page.  The downside of this is that the user actually lands on /errors/, so the URL changes to the error page URL rather than the URL for the page that generated the error.  If anyone has questions, feel free to ask me, as I've spent hours and hours trying to work through this, and this was the only solution that actually worked.

View solution in original post

3 Replies
Vijayalakshmi_S
Community Advisor
Community Advisor

Hi @evancooperman-rp,

Could you please check the ACS commons 500 behavior in AEM as Cloud Publish Service instance.

If you have already, is it the same response as you have shared in the screenshot?

 

evancooperman-rp
Level 2
Level 2

It's the same behavior in both author and publish, in both cases I get the screenshot (but in author I still get the author scaffolding and can edit page properties and such, where in publish I'm fully dead in the water and can't do anything. 

It works as expected locally though, with 500 errors, using the AEMaaCS SDK.

evancooperman-rp
Correct answer by
Level 2
Level 2

In working with the Adobe support team, it seems I'm not the only one having these issues with AEMaaCS.  There is a ticket in the engineering backlog to deal with it, and not much we can do for now.  There's only 1 way I've found I can skirt the Adobe error page, which is to move error handling from AEM to Apache, by changing

DispatcherPassError    0

to

DispatcherPassError    1

 and then adding ErrorDocument lines for each http status code we want to handle, and the associated page we want to handle it with.  This is much less ideal than using ACS Commons since an author has no control over which errors go to which pages, but at least it allows us to render a custom error page rather than showing end-users the Adobe error page.

That being said, this alone does not work.  Just doing this, the Adobe error page persists.  The only way to actually get the system to render your custom error page for 500 errors, for example, is to use a 301 or 302 redirect from the path you set, to a different page.  This interrupts the dispatcher rewrite processing, and then actually sends the user to your page rather than the Adobe error page.  For example we have a rewrite rule that strips .html from the end of our URLs, and adds a "/".  So, when I set up my ErrorDocument, I intentionally use the non-rewritten URL of /errors.html, which will then hit my rewrite rules and get 301 redirected to /errors/

In this way I was able to short-circuit the cloud dispatcher logic (that is out of my control) and actually send the user to our custom error page.  The downside of this is that the user actually lands on /errors/, so the URL changes to the error page URL rather than the URL for the page that generated the error.  If anyone has questions, feel free to ask me, as I've spent hours and hours trying to work through this, and this was the only solution that actually worked.

View solution in original post