AEMaaCS - Error Handling using the acs-aem-commons package | Community
Skip to main content
E
evancooperman-rp
Level 3
October 26, 2021
Solved

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

  • October 26, 2021
  • 4 replies
  • 7201 views

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-service-feature-incompatibility - 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/full-stack/custom-error-page.html?lang=en 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

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by evancooperman-rp

    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.

    4 replies

    Vijayalakshmi_S
    Vijayalakshmi_S
    Level 10
    October 27, 2021

    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?

     

      E
      evancooperman-rpAuthor
      Level 3
      October 27, 2021

      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.

        E
        evancooperman-rpAuthorAccepted solution
        Level 3
        November 4, 2021

        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.

        L
        lchis
        January 19, 2023

        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?

        S
        SainathReddy_K
        January 20, 2022

        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

        E
        evancooperman-rpAuthor
        Level 3
        January 20, 2022

        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!

          S
          SainathReddy_K
          January 21, 2022

          Hi @evancooperman-rp ,

          Thanks a lot, the solution suggested is working

          joerghoh
          Adobe Employee
          joerghohAdobe Employee
          Adobe Employee
          October 11, 2024

          For reference: it has been implemented in the meanwhile, see https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/content-delivery/custom-error-pages (CDN error pages)

          Terms & ConditionsAccessibility statement

          Loading footer...