Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Dispatcher creating html files as directories

JLoureiro
Level 1
Level 1
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
Jörg_Hoh
Correct answer by
Employee
Employee

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
Jörg_Hoh
Correct answer by
Employee
Employee

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.

 

 

 

 

JLoureiro
Level 1
Level 1

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.