Redirect for a PDF file is not working about retour

[khalwat]

Ahhhhh that all makes sense now! Thanks for letting me know the cause.

[khalwat]

Show me a screenshot of the 404 you're seeing when visiting that original URL to the PDF?

[sm9]

Hi Andrew, of course. Can I email you this? If so, what is the best address to send this to? Thanks.

[khalwat]

All I'm trying to determine is where it is an Nginx/Apache 404 error that's being displayed, or whether it is a Craft 404 error that's being displayed.

I can tell this by looking at what the 404 error message looks like; if it's a generic error message, then it's coming from your webserver. If it's a nicely formatted message, then it's coming from Craft.

This is relevant because if the 404 is coming from your webserver, and not Craft, then Retour never gets a chance to handle it.

Often this is the case because static resources like .pdf files are configured to bypass Craft, and be served up directly by the webserver.

I suspect that's the case here, and if so, there's no way Retour can handle the redirect. You'll have to user a server-side redirect.

[sm9]

Hi Andrew,

I just didn't want to post a client's screenshot publicly.

When logged into Craft as an admin, this is the 404 we see (I used the web inspector console to edit the URLs/paths: https://capture.dropbox.com/BRtgRkKO2PhEkktB

When not logged into Craft, we see the website's formatted/designed 404 template.

Thanks,

Stephen

[khalwat]

Okay so it is going through Craft -- so the Legacy URI must not be matching for some reason

[sm9]

The Legacy URI matches (unless anything else is going on with the Forge/Nginx config that we haven't noticed), and we have tried Path Only as well as a Full URL. No matter how many times we refresh the old URL and load a 404, the Hits counter never rises above zero though, so Retour/Craft isn't seeing it for some reason, which is why we wondered if it was a bug with PDF's.

A redirect for https://www.ourwebsite.com/testing123/filename works fine, but a redirect for https://www.ourwebsite.com/testing123/filename.pdf doesn't work.

Do you have any other thoughts for things we might need to check for this at all? Thanks.

[khalwat]

Is it possible the . needs to be escaped? I'll do some tests locally tomorrow to see if I can reproduce the issue here.

I really thought it was going to be that the static assets weren't routed through Craft (which is ideally what you'd want), but I'm guessing even if that's the case, the 404 does get routed through Craft.

[khalwat]

Okay I did a test locally and everything is working as expected with the example URLs you note above.

Therefore, I'm guessing there is some kind of server config issue on your end that might be interfering here?

[sm9]

Hi Andrew,

Thanks for looking into this one further.

You mentioned the server config, so I've copied and pasted our Laravel Forge Nginx config below for info in case anything jumps out at you that might explain the issue we're having (or to rule out this being an issue):

# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/www.clientdomain.com/before/*;

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.clientdomain.com;
    server_tokens off;
    root /home/forge/www.clientdomain.com/public;

    # FORGE SSL (DO NOT REMOVE!)
    ssl_certificate /etc/nginx/ssl/www.clientdomain.com/1234567/server.crt;
    ssl_certificate_key /etc/nginx/ssl/www.clientdomain.com/1234567/server.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers <ciphers removed>;
    ssl_prefer_server_ciphers off;
    ssl_dhparam /etc/nginx/dhparams.pem;
    
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    # FORGE CONFIG (DO NOT REMOVE!)
    include forge-conf/www.clientdomain.com/server/*;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/www.clientdomain.com-error.log error;

    error_page 404 /index.php;
    
    rewrite ^/(.*)/$ /$1 permanent;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
    
    location ~* (.+)\.(?:\d+)\.(js|css|png|jpg|jpeg|gif|webp)$ {
        try_files $uri $1.$2;
    }
}

# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/www.clientdomain.com/after/*;

Let me know if you spot any issues with anything here, or would like us to try anything else.

Thanks,

Stephen

[khalwat]

I don't see anything in there explicitly setting a location block for pdf files, so no, nothing offhand.

Are you able to reproduce this issue in your local dev environment?

[sm9]

Hi Andrew, sorry for the delay in coming back to you about this one. I've tested this in a development environment today (using MAMP) and the same issue was happening there. After a lot of debugging, trial and error (and disabling other plugins, one by one), I eventually came across the cause of the issue! 😅

We had this in our Retour settings: Exclude Patterns: \.jpg|\.png|\.bmp|\.gif|\.pdf|\.doc|\.docx

Once I removed the .pdf bit and saved the settings, the redirect worked fine and as expected!

The reason we added that pattern in the first place was because the Asset path changed after we implemented multi-site functionality a couple of years ago, and our Retour dashboard was getting filled up with 404s for files that had changed path, but which we didn't think were important to see/redirect, so we added the pattern to filter this 'junk' out. Little did we know then, that the client would want to add a redirect for a PDF file a couple of years later!

Sorry about this and for wasting your time helping us get to the bottom of it, but your help was much appreciated! Thanks, Stephen