Hey guys,
I have a problem here where certain a request is returning a 302. It's a request to an asset that very much exists.
So
/content/dam/image.svg 302-> /content/dam/image.svg/
Which then gets a 403.
I would like to be able to debug this except that Adobe does not provide the source code for the filter chain, so it's just one big black box of broken pain that I can't navigate.
How do I get the source code?
I promise, sharing more source code won't hurt your sales. No one is going to try to cobble together an unsupported AEM from the source jars you guys hypothetically provide. You are only ruining the name of AEM in the dev community by not providing it.
BTW, this is 6.5 SP7
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @jkpanera!
As already mentioned by some other members of this community, I would suggest to perform some root cause analysis on the issue that you are outlining. Some questions that should be answered before pointing to the AEM product source code would be:
However, from my experience and without further knowledge about your setup or what you have already checked, I would most likely suspect this to be a dispatcher issue or somehow related to URL manipulation. You may want to check this article for potential candidates that could lead to the described behavior.
Once you have gained some more insights about the root cause, you may find a resolution somewhere in your specific setup (code, configuration, etc.). If you have indications that this might be a product issue, feel free to create a support ticket for our customer care team.
While I understand your desire to debug through closed-source AEM product code to a certain degree, this is usually not necessary (and often barely helpful) for this kind of analysis. You won't be able to patch anything for internal code. Even if you try or do so, you will loose support. For a proper analysis, there are plenty of tools available (within AEM and the stack as well as general Java analysis tools). From my personal experience, debugging through product internal source code is only helpful in rare edge cases.
If you still feel that AEM should be completely open-sourced, you may post this as a kind of feature request on this community (I'm not judging about chances of success here).
Hope that helps!
From the 302 redirect, it looks like an issue with your apache web server dispatcher configuration. Did allow .svg files from being reached?
Views
Replies
Total Likes
Views
Replies
Total Likes
If you are able to reproduce the issue on publish instance, then it will be an issue with sling:internalRedirect. Do you have any etc/maps rules configured on your instance?
Please remove all your etc/maps config from publish and check if it's reproducible on publish instance.
Else the other location is JCRResourceResolverFactory config where the mapping can be present.
Hi @jkpanera ,
If it is happening on webserver then must be because of rewrite module in apache and rules configured there (redirect rules). Just enable the rewrite logs in apache to debug.
Views
Replies
Total Likes
Hi @jkpanera!
As already mentioned by some other members of this community, I would suggest to perform some root cause analysis on the issue that you are outlining. Some questions that should be answered before pointing to the AEM product source code would be:
However, from my experience and without further knowledge about your setup or what you have already checked, I would most likely suspect this to be a dispatcher issue or somehow related to URL manipulation. You may want to check this article for potential candidates that could lead to the described behavior.
Once you have gained some more insights about the root cause, you may find a resolution somewhere in your specific setup (code, configuration, etc.). If you have indications that this might be a product issue, feel free to create a support ticket for our customer care team.
While I understand your desire to debug through closed-source AEM product code to a certain degree, this is usually not necessary (and often barely helpful) for this kind of analysis. You won't be able to patch anything for internal code. Even if you try or do so, you will loose support. For a proper analysis, there are plenty of tools available (within AEM and the stack as well as general Java analysis tools). From my personal experience, debugging through product internal source code is only helpful in rare edge cases.
If you still feel that AEM should be completely open-sourced, you may post this as a kind of feature request on this community (I'm not judging about chances of success here).
Hope that helps!
Views
Likes
Replies
Views
Likes
Replies