AEM postback gives HTTP 204 instead of HTTP 200 | Community
Skip to main content
R
rohan_pulekar
October 22, 2020
Solved

AEM postback gives HTTP 204 instead of HTTP 200

  • October 22, 2020
  • 2 replies
  • 7072 views

The setup:
I am working on a website hosted in AEM.
There is a Single page app (SPA) on the website for a certain transactional flow.
In this transactional flow SPA there is a payment step where user enters credit card details.
For this payment step I show user an iframe that is hosted by a third party payment processor.
After user enters their credit card and clicks submit, the payment processor does a postback to a success URL on my host website.
The postback is POST ..../reserve.paymentsuccess.html  where reserve is the SPA page and paymentsuccess is a custom AEM selector I have created in my website code as:   apps/cq/Page/paymentsuccess.POST.html
So this POST goes to AEM publisher which gives response HTTP 200 and in response body it gives the html that I have in /apps/cq/Page/paymentsuccess.POST.html .  This html is just:  
<script type="application/javascript"> window.parent.postMessage({type: 'payment-redirect', success: true, paymentSessionId: paymentSessionId}, "*");</script>

this all works fine on prod, on all staging environments, and developers local machine.

 

The issue:
On just one AEM publisher of a particular staging environment, the  POST ..../reserve.paymentsuccess.html   is giving HTTP 204 with no response body.  And since there is no response body window.parent.postMessage mentioned never happens and user gets stuck there.
Any idea why this one staging environment AEM publisher would erroneously give HTTP 204 instead of HTTP 200

    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 davidjgonzalezzzz

    Hi,

     

    Using the AEM Web Console (aka Felix console), use the "Sling Servlet Resolver" tool on the misbehaving AEM Publish node to see what servlet the POST request resolves to:

     

    http://localhost:4502/system/console/servletresolver

     

    You can compare this a "working" Publish node. The Servlet Resolver can sometimes act a bit wonky, so alternatively, you can make your POST to the end-point in question, and review

     

    Recent requests: http://localhost:4502/system/console/requests

     

    This will show the FULL trace of of how the request is processed. 

     

    If it is resolving to your script properly, then it sounds like there is an issue w/ the script on that Publish node. Review the script, and even try making a benign change to it to force a recompile.

    If these tools DONT show the expected script, then it sounds like your script is not deployed correctly; review to make sure it exists in the expected location under /apps.

     

    What youre doing should certainly work, but i figure i'd mention my preferred pattern for attaching selectors to cq:Page resources is using a Sling Opting Servlet as shown here: https://github.com/Adobe-Consulting-Services/acs-aem-samples/blob/master/core/src/main/java/com/adobe/acs/samples/servlets/impl/SampleOptingServlet.java

    Writing Java code in a bonafide Java class is cleaner, more testable, and easier to trace/log/debug (IMO). You can also tie your behavior to specific cq:Page's easily with the Opting check, rather than attaching the POST paymentsuccess to EVERY cq:Page. 

    2 replies

    D
    Adobe Employee
    davidjgonzalezzzzAdobe EmployeeAccepted solution
    Adobe Employee
    October 22, 2020

    Hi,

     

    Using the AEM Web Console (aka Felix console), use the "Sling Servlet Resolver" tool on the misbehaving AEM Publish node to see what servlet the POST request resolves to:

     

    http://localhost:4502/system/console/servletresolver

     

    You can compare this a "working" Publish node. The Servlet Resolver can sometimes act a bit wonky, so alternatively, you can make your POST to the end-point in question, and review

     

    Recent requests: http://localhost:4502/system/console/requests

     

    This will show the FULL trace of of how the request is processed. 

     

    If it is resolving to your script properly, then it sounds like there is an issue w/ the script on that Publish node. Review the script, and even try making a benign change to it to force a recompile.

    If these tools DONT show the expected script, then it sounds like your script is not deployed correctly; review to make sure it exists in the expected location under /apps.

     

    What youre doing should certainly work, but i figure i'd mention my preferred pattern for attaching selectors to cq:Page resources is using a Sling Opting Servlet as shown here: https://github.com/Adobe-Consulting-Services/acs-aem-samples/blob/master/core/src/main/java/com/adobe/acs/samples/servlets/impl/SampleOptingServlet.java

    Writing Java code in a bonafide Java class is cleaner, more testable, and easier to trace/log/debug (IMO). You can also tie your behavior to specific cq:Page's easily with the Opting check, rather than attaching the POST paymentsuccess to EVERY cq:Page. 

      R
      rajput-ankur
      June 21, 2021
      I am also facing a similar kind of issue in case of SAML. When the IdP is redirecting to AEM with SAMLResponse, it is returning 204 No Content. But if I execute the same request through Postman then it is working perfectly fine. I couldn't find the request neither in request and access logs nor on Recent requests console: http://localhost:4502/system/console/requests. I even added a breakpoint on SlingMainServlet and the request is not even coming to that,
      ottón63171937
      ottón63171937
      August 17, 2021

      Check Adobe Granite Cross-Origin Resource Sharing Policy OSGi config entries on publishers to make sure that the IdP's origin is an explicitly allowed origin or use .* regexp as allowed origins regexp.

        Ankur_Khare
        Community Advisor
        Ankur_KhareCommunity Advisor
        Community Advisor
        October 22, 2020

        Hope the code is same on staging server?

        And could please add logs..

          Terms & ConditionsAccessibility statement

          Loading footer...