AEM postback gives HTTP 204 instead of HTTP 200

[rohan_pulekar]

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

[davidjgonzalezz · Accepted solution]

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/adob...

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. 

[rajput-ankur]

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]

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.

[iabhisheksinha1]

Hi @ottón63171937 & @rajput-ankur 
I'm facing the similar issue of getting response code - 204 in case of SAML to AEM request
My AEM servlet is not triggered due this & after updating Adobe Granite Cross-Origin Resource Sharing Policy with required value as mentioned above, I'm not getting a 403 error instead. If I revert the CORS value, the response code is 204 again.

Can you suggest anything here please?

[Praveen_Kasaraj]

Your answer helped me to resolve the 204 issues with SAML login. One of our team members updated the Allowed Origin value with localhost. I was farting around the SAML configurations and with Authentication teams to check the issue. After googling sometime, I have landed to your reply. Solved the problem quickly. I appreciate you sharing this knowledge.

Thank you Otton63171937

[Ankur_Khare]

Hope the code is same on staging server?

And could please add logs..