Adobe Experience Manager Sites & More

evancooperman-rp · 10/26/21

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:

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

evancooperman-rp · 11/4/21

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

Vijayalakshmi_S · 10/27/21

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 · 10/27/21

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 · 11/4/21

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.

lchis · 1/18/23

Really appreciate that answer, I'm going through it now and trying to apply it but not quite getting the desired result. My steps are as follows

1. In my available and enabled vhosts files under conf.d, I added

ErrorDocument 404 /redirect/error

after the "DocumentRoot" entry

2. In those same files, I switched DispatcherPassError to 1.

3. You mentioned that the ErrorDocument that is set needs to go through a 301 redirect, so I intentionally did not set it to a real page. I set it to "/redirect/error" as mentioned, and added this rewrite in my rewrite.rules file:

RewriteRule /redirect/error /content/druvaincprogram/us/en/errors/404.html [R=301]

I still get the Adobe

Resource at '/content/druvaincprogram/us/en/test22.html' not found: No resource found

Message after all that. Anything I'm missing?

SainathReddy_K · 1/19/22

Hi @evancooperman-rp ,

I'm facing similar issue with the 500 error page and tried the DispatcherPassError set to 1 and ErrorDocument setup but still have no luck with the AEMaaCS environments. Can you help me with the mapping or if there is any other steps to be performed for redirection

evancooperman-rp · 1/19/22

For 500 errors, you need to set up the error page to 301 redirect to another page. This will interrupt the redirect chain that Adobe has in place to send you to their error page. So basically set up your error page to point to

/my-custom-error-page

and then in your rewrite rules, set up a 301 redirect for /my-custom-error-page that points to the page you actually want the user to hit. This will then force them to your page and prevent the Adobe error page from displaying. The only caveat is that the URL will then change to your error page URL, but this is the only way to bypass their error page that I know of. Hopefully they'll give us a way to supercede their error page soon, my understanding is that's in the roadmap for the engineering team.

Hope that helps!