Hi Team,
I have my GRAPHQL URL Below, which returns a valid json format when the fragment path was wrong its should redirect to our project 404/500 error pages.
for example:
localhost:4502/graphql/execute.json/consumer-bau/bau-popup;fragmentpath=/content/dam/cfm-company/bau-consumer/life/additional-benefits/popup/benefits-main-sec;variation=master -returns valid json format
when fragment path were incorrect as below
localhost:4502/graphql/execute.json/consumer-bau/bau-popup;fragmentpathInvalidpath=/content1111111/dam/cfm-company/bau-consumer/life/additional-benefits/popup/benefits-main-sec;variation=master? - which returns error json format, in network, tab it returns 200 ok status code.
My question was how to redirect such invalid json or cfm path to project 404/500 error page.?
instead dispatcher rewrite rule, is there any way to handle via code?
As we aware 404/500, was only for invalid page(primary type: cq:page). for primary type ==> dam:Asset how to redirect to 404/500 page. Kindly suggest. Thanks!!
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
Technically it seems correct that the 200 status is returned because this status highlights the communication between server and client, and even if the results are wrong for your application, the communication was ok, hence 200 is ok. That means that the application that will consume the JSON will be responsible for handling this response and treating it as an error. All this explanation is for you to understand that whoever uses this API should handle the error on their end, what you are trying to do is not necessarily the best approach by definition. However, if you want to achieve such behavior, I would look to the servlet filter functionality https://medium.com/@techzette2/sling-filters-understanding-and-utilizing-the-capabilities-of-aem-8d5...to see if you can wrap the response.
Hope this helps
Views
Replies
Total Likes
Hi,
Technically it seems correct that the 200 status is returned because this status highlights the communication between server and client, and even if the results are wrong for your application, the communication was ok, hence 200 is ok. That means that the application that will consume the JSON will be responsible for handling this response and treating it as an error. All this explanation is for you to understand that whoever uses this API should handle the error on their end, what you are trying to do is not necessarily the best approach by definition. However, if you want to achieve such behavior, I would look to the servlet filter functionality https://medium.com/@techzette2/sling-filters-understanding-and-utilizing-the-capabilities-of-aem-8d5...to see if you can wrap the response.
Hope this helps
Views
Replies
Total Likes
Hi @EstebanBustamante , thanks much for your response, this will help for my further analysis
Views
Replies
Total Likes
Views
Likes
Replies