Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Dispatcher creating html files as directories

Avatar

Level 2
Dispatcher is creating html cached files as directories.
- Directory file being incorrectly created is inside basket folder, eg: content/basket/checkout.html
- When customer tries to access those files he receives a http 3XX or 4XX error.

For instance running the following linux cmd inside dispatcher cache directory:
 find . -type d | cut -c 10- | grep '\.' | grep -o '....$' | sort | uniq -c
will result in :
10 .html
5 .gif
2024 .jpg
2571 .png

Why dispatcher is creating files as directories? Is this an intended behaviour for some circustances? What can be leading to this behavior?

Details:
- Accessing the .html page in any publisher instance returns successfully the html content.
- Manually clearing this directory from file system temporarily (days) solves the issue.

In dispatcher rules we have configured a rule to not cache under the specific folder where we see the issues:
/cache
{
/rules
{
….
/0005
{
/glob "*/basket/*.html"
/type "deny"
}
No allow rule is configured after this deny rule.
Even so the invalid file is being created.

We have 4 dispatchers connected in a 1-1 relationship with 4 publishers.
Environment is running on AWS EC2 Linux Red Hat 7, every single application is hosted on its own instance. The issue occurs randomly only in one dispatcher at a time.
AEM version: Adobe Experience Manager (6.5.8.0).
Dispatcher version is 4.3.3 and apache version is Apache/2.4.46 (Unix).
Java on publishers is JDK 1.8.0.251.
We’ve checked dispatcher.logs, apache logs, publisher logs and can’t find any abnormal accesses or issues. 
1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Imagine to have these valid URLs:

 

/content/basket/checkout.html

/content/basket/checkout.html/suffix.html

 

Both are valid URLs for AEM/Sling and both can be cached in the dispatcher. 

 

In the filesystem this looks like this:

 

DOCROOT

DOCROOT/content

DOCROOT/content/basket.html

DOCROOT/content/basket/checkout.html <--------

DOCROOT/content/basket/checkout.html/suffix.html

 

In a fiilesystem the path DOCROOT/content/basket/checkout.hml can be either a directory or a file, but not both. A depending what path is cached first it is created either as a directory or a file.

 

The only way to fix it is to make the decision upfront, it if should be a directory or a file, and then create the URLs/requests accoringly.

 

For example a request to /content/basket/checkout.html could be a redirect to /content/basket/checkout.html/defaultSuffix.html. Or turning the suffix into a selector.

 

 

 

 

View solution in original post

2 Replies

Avatar

Correct answer by
Employee Advisor

Imagine to have these valid URLs:

 

/content/basket/checkout.html

/content/basket/checkout.html/suffix.html

 

Both are valid URLs for AEM/Sling and both can be cached in the dispatcher. 

 

In the filesystem this looks like this:

 

DOCROOT

DOCROOT/content

DOCROOT/content/basket.html

DOCROOT/content/basket/checkout.html <--------

DOCROOT/content/basket/checkout.html/suffix.html

 

In a fiilesystem the path DOCROOT/content/basket/checkout.hml can be either a directory or a file, but not both. A depending what path is cached first it is created either as a directory or a file.

 

The only way to fix it is to make the decision upfront, it if should be a directory or a file, and then create the URLs/requests accoringly.

 

For example a request to /content/basket/checkout.html could be a redirect to /content/basket/checkout.html/defaultSuffix.html. Or turning the suffix into a selector.

 

 

 

 

Avatar

Level 2

Thanks for the way forward.

On access logs we were able to figure out that on specific conditions and only for Dalvik (User Agent) browsers there was being requested a favicon as basket.html/favicon that was generating this issue.

 

This URL was an invalid one so it was fixed.