Source code to troubleshoot 302 redirect issue

[jkpanera]

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

[BrianKasingli]

@jkpanera,

From the 302 redirect, it looks like an issue with your apache web server dispatcher configuration. Did allow .svg files from being reached?

[jkpanera]

It certainly isn't a dispatcher issue. I thought that at first, too. I can reproduce it on publish alone.

[BrianKasingli]

Can you check your etc.mappings, maybe there might be a rule in there was redirects an asset if the asset mime Type is unknown to your configurations.

[Asutosh_Jena_]

Hi @jkpanera @jkpanera 

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.

[Ritesh_Mittal]

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.

[jkpanera]

Nope. That's what I thought too. It's reproducible directly on publish.

[markus_bulla_adobe · Accepted solution]

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:

• What instance is causing the redirect? AEM author instance? AEM publish instance?
• Could the redirect be caused by the webserver and/or dispatcher? Have you tried requesting the asset directly from the AEM instance, no dispatcher involved?
• Is the issue reproducible a.) on other environments and/or b.) on a plain vanilla instance?
• Have you tried deactivating some potential candidates that could cause the redirect to identify the actual root?
• Have you checked resource resolution and mappings (in the OSGI web console) to see how the request is resolved?
• You may also want to check the "Recent requests" view to get an insight into the applied filter chain as this is something that you specifically mention as something that you are looking for.

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!