redirect cfm graphql url to 404/500 page,if not valid get request | Community
Skip to main content
R
rajat168
Level 4
March 19, 2024
Solved

redirect cfm graphql url to 404/500 page,if not valid get request

  • March 19, 2024
  • 1 reply
  • 1191 views

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!!

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 EstebanBustamante

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-8d5306608b54 to see if you can wrap the response.

 

Hope this helps

 

 

1 reply

EstebanBustamante
Community Advisor and Adobe Champion
EstebanBustamanteCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
March 19, 2024

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-8d5306608b54 to see if you can wrap the response.

 

Hope this helps

 

 

Esteban Bustamante
R
rajat168Author
Level 4
March 20, 2024

Hi @estebanbustamante , thanks much for your response, this will help for my further analysis

Terms & ConditionsAccessibility statement

Loading footer...