Question Feature Request: Case-Insensitive Support for "Serve static files directly by nginx"

[nethubonline]

Server operating system version

AlmaLinux release 9.3

Plesk version and microupdate number

18.0.70

Dear Plesk Team,

I would like to report a limitation in the current implementation of the “Serve static files directly by nginx” feature. At present, the generated nginx directives use the ~ regex modifier, which performs case-sensitive matching.

This causes an issue where static files with uppercase extensions (e.g., .JPG, .PNG, .CSS) are not served directly by nginx, even though they should logically be treated the same as .jpg or .docx.

Enabling case-insensitive matching is very simple and straightforward:

• Change the regex modifier from ~ to ~* in the nginx location block.
• For example:
  
  

  location ~* ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|woff|woff2|xls|xlsx|zip|webp))$ {
      ...
  }

This small adjustment would ensure consistent behavior regardless of file extension casing, improve user experience, and align nginx’s static file handling with real-world file usage.

Thank you for considering this improvement.

 

[Hangover2]

@nethubonline

In the past, others and I tried to bring attention to this bug, but Plesk refused to make any changes. You will need to patch it yourself. Please see my workaround in the following topic:

Smart static files processing is only working for lowercase file extensions

 

[Sebahat.hadzhi]

Before I bring that for further discussion with our team I would like to know if there are any other valid cases apart from users unintentionally uploading such files. Thank you in advance.

 

[nethubonline]

Thanks Sebahat!

In our view, the only valid case is when users unintentionally upload such files.

FYI, I replied to the post below a few hours ago. Thank you!

Smart static files processing is only working for lowercase file extensions

 

[Sebahat.hadzhi]

Thank you. Yes, I saw the reply and I will forward the details to our team. I will follow-up once I have more information.

 

[Hangover2]

Yes—there are several valid, non-“user mistake” cases where case-insensitive extension matching is desirable:

• Cross-platform workflows: Assets often originate on Windows or default case-insensitive macOS volumes. Tools (camera exports, design apps, DAMs) routinely produce .JPG, .PNG, .CSS, etc. Uppercase isn’t accidental—it’s just how the upstream system wrote them.
• Legacy migrations: Sites moved from IIS/Windows (case-insensitive URLs) or older CDNs/storage buckets can contain mixed-case extensions. Keeping nginx strict here creates avoidable 404s or needless backend passes.
• Automated pipelines: Build steps or renamers (e.g., marketing renames, batch scripts) sometimes normalize to uppercase or title-case. This isn’t a user “upload” action but an automated process.
• Inbound links at scale: External sites, newsletters, social schedulers, or UTM builders may paste or transform links with uppercase extensions. We can’t control those, but we do want them to resolve.
• App/library behaviors: Some libraries concatenate filenames and call .toUpperCase()/.toLocaleUpperCase() (the classic “Turkish I” shows up here). The app is correct semantically, but nginx’s case-sensitive regex turns it into a cache miss.

Practical benefits of ~* here:

• Performance & stability: When the regex misses due to case, assets fall through to the backend (Apache/PHP-FPM/app), increasing latency and load. Case-insensitive matching keeps static files on the fast path and reduces the application attack surface.
• Backward compatibility: It avoids breaking sites during migrations or refactors where extension casing wasn’t standardized.
• Minimal risk & complexity: This change only broadens matches for known static extensions; it doesn’t alter routing for non-matching paths. The PCRE ~* cost is negligible compared to a backend hop.

Implementation options:

1. Simple default: Switch the generated location to ~* for the “Serve static files directly by nginx” block.
2. Configurable toggle: Add a checkbox like “Treat static file extensions case-insensitively,” default on, preserving an opt-out for strict environments.
3. Inline alternative: Keep ~ but add (?i) in the pattern (PCRE) to scope case-insensitivity precisely to this location.

If helpful, I can share example server logs showing backend hits caused solely by casing differences. But functionally, this is a small, safe tweak that improves UX and efficiency across common, modern workflows.

Thanks for considering!

 

[trialotto]

@Hangover2

First of all, thank you for the excellent post!


This set of options

Implementation options:

1. Simple default: Switch the generated location to ~* for the “Serve static files directly by nginx” block.
2. Configurable toggle: Add a checkbox like “Treat static file extensions case-insensitively,” default on, preserving an opt-out for strict environments.
3. Inline alternative: Keep ~ but add (?i) in the pattern (PCRE) to scope case-insensitivity precisely to this location.

can be simplified to : default config with ~* .... and option to switch that off in panel.ini !

The toggle might be a good idea, but I would not be a fan (and it would not add value), if and when it is enabled by default.

The "inline alternative" is not viable within the Plesk + Nginx environment and certainly not when "readability (of regex)" is at stake.

I firmly believe that (regex) readability is at stake, in the sense that it should be as simple as possible for most Plesk admins - for many reasons.


As a final remark, please note that there is a security consideration to be made here.

The presence of media files with uppercase extensions is often a signal for malicious parties that "vulnerable software" is present on the system and/or that media is present that comes from "vulnerable systems" (read: pointing an arrow to a door that is unlocked, to state it differently).

Other than that, there should not be any reason to implement the ~* by default.


Kind regards....