Problem opening files with encoded filenames

Question

I have a website where users can upload files, if they upload a file with a special character in the filename, the filename will be encoded (for example: iordănescu.pdf will become iord%C4%83nescu.pdf)

This causes some problems to be able to open these files from a link on the website. The CMS provides a link like this one: example.com/frontend/files/jobs/iord%C4%83nescu.pdf.

But it only works when the encoded filename is encoded (so double encoded) like this: example.com/frontend/files/jobs/iord%25C4%2583nescu.pdf.

Can I write a rule in my .htaccess file to make the filenames double encoded? Or is there something else I can try?

I've updated my current .htaccess file, which is saved in the same folder where the files are uploaded to, to the suggestion of MrWhite:

Options +FollowSymLinks -MultiViews

RewriteEngine On

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{THE_REQUEST} "^GET /(.*%.*) HTTP/"
RewriteRule \.(pdf|jpg|png)$ /%1 [B,L]

This now gives me the following error:

The requested URL /frontend/files/jobs/iord%C4%83nescu.pdf was not found on this server.

Which is how I see the file via FTP, but if I copy the path via FTP it appears to be double encoded already:

/www/frontend/files/jobs/iord%25C4%2583nescu.pdf

Side note:

This website has been developed by someone else and is rather old. I am now responsible for maintaining this website and the client informed me about this issue. Since this website will be completely redone soon I don't want to spend too much time on creating a fix so being able to solve it via .htaccess would be ideal.

Answer 1

Ideally, this should be "fixed" in the backend code, as there appears to be two "bugs" here...

1. The uploaded file should not be saved with a %-encoded filename. This is a URL-encoding, intended for transit, not a filesystem encoding.

2. The generated link is not being correctly URL encoded. If the underlying filename is "URL encoded" then the generated link should already be "doubly" encoded.

However, this can be "worked around" in .htaccess with a URL-rewrite. I would avoid a Redirect. If you redirect then you are doubling the requests, putting extra load on the server, slowing the user and depending on the user-agent for part of the URL-encoding process.

You also need to be as specific as possible with the URLs you target as you need to avoid doubly encoding any legitimate URL that shouldn't be!

You need to clarify the URL and filesystem paths, as this is currently not clear in your question - your example URLs and .htaccess directives appear to target different things?

For the sake of this example, I will assume the user can only upload .pdf, .jpg and .png files.

In the .htaccess file in the directory where the files are uploaded, try something like the following using mod_rewrite:

Options +FollowSymLinks -MultiViews

RewriteEngine On

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteCond %{THE_REQUEST} "^GET /(.*%.*) HTTP/"
RewriteRule \.(pdf|jpg|png)$ /%1 [B,L]

The RewriteRule pattern matches the location and type of files that can be uploaded. We can't simply capture the URL-path using the RewriteRule pattern (as you are doing in your example), because the URL-path that the RewriteRule pattern matches against is already %-decoded. Instead, we grab the (hopefully) single-encoded-URL from THE_REQUEST server variable. THE_REQUEST contains the first line of the HTTP request and contains the (encoded) root-relative URL as sent from the client. We check that the request contains at least one % - so we know it is %-encoded.

The %1 backreference (note the % prefix, not $) references the captured subpattern in the last matched condition (ie. the encoded URL). The B flag ensures that this backreference is URL encoded (again).

The first condition that checks against the REDIRECT_STATUS environment variable ensures that we only examine the initial request from the client and not the rewritten request by our directive. This avoids an endless rewrite loop. We only need to loop once.