[Bug]: Redirected to /xx when site is secured

[beneverard]

Platform

macOS

Operating system version

macOS Sonama 14.6.1

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.11.0 (Build: 33)

PHP Version

No response

Bug description

When visiting an unsecured site everything works as expected, however, after securing a site, visiting it redirects to a /xx where xx is a two-digit number.

In issue #503 @mpociot mentions that Herd doesn't redirect and it's likely something in the user's application. I was curious about this, so I checked the Nginx configuration and found that the configs seem to be malformed, see here for ssl.test:

server {
    listen 127.0.0.1:80;
    #listen 127.0.0.1:80; # valet loopback
    server_name ssl.test www.ssl.test *.ssl.test;
    return 301 https://$host$request_uri;
}

server {
    listen 127.0.0.1:443 ssl;
    #listen VALET_LOOPBACK:443 ssl; # valet loopback
    server_name ssl.test www.ssl.test *.ssl.test;
    root /;
    charset utf-8;
    client_max_body_size 1024M;
    http2 on;

    location /41c270e4-5535-4daa-b23e-c269744c2f45/ {
        internal;
        alias /;
        try_files $uri $uri/;
    }

    ssl_certificate "/Users/beneverard/Library/Application Support/Herd/config/valet/Certificates/ssl.test.crt";
    ssl_certificate_key "/Users/beneverard/Library/Application Support/Herd/config/valet/Certificates/ssl.test.key";

    location / {
        rewrite ^ "26" last; # <<<<<<<<<<<<<<<<<<<<<<<
    }

    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 "/Users/beneverard/Library/Application Support/Herd/Log/nginx-error.log";

    error_page 404 "26"; # <<<<<<<<<<<<<<<<<<<<<<<

    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass $herd_sock;
        fastcgi_index "26"; # <<<<<<<<<<<<<<<<<<<<<<<
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME "26"; # <<<<<<<<<<<<<<<<<<<<<<<
        fastcgi_param HERD_HOME "/Users/beneverard/Library/Application Support/Herd";
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location ~ /\.ht {
        deny all;
    }
}

server {
    listen 127.0.0.1:60;
    #listen 127.0.0.1:60; # valet loopback
    server_name ssl.test www.ssl.test *.ssl.test;
    root /;
    charset utf-8;
    client_max_body_size 1024M;

    add_header X-Robots-Tag 'noindex, nofollow, nosnippet, noarchive';

    location /41c270e4-5535-4daa-b23e-c269744c2f45/ {
        internal;
        alias /;
        try_files $uri $uri/;
    }

    location / {
        rewrite ^ "26" last; # <<<<<<<<<<<<<<<<<<<<<<<
    }

    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 "/Users/beneverard/Library/Application Support/Herd/Log/nginx-error.log";

    error_page 404 "26";

    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass "unix:/Users/beneverard/Library/Application Support/Herd/herd.sock";
        fastcgi_index "26"; # <<<<<<<<<<<<<<<<<<<<<<<
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME "26"; # <<<<<<<<<<<<<<<<<<<<<<<
        fastcgi_param HERD_HOME "/Users/beneverard/Library/Application Support/Herd";
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location ~ /\.ht {
        deny all;
    }
}

When comparing this Nginx config against one from a colleague all instances of "26" are incorrect (see <<<< comments), and when changing this to "/Applications/Herd.app/Contents/Resources/valet/server.php" and restarting Herd resolves the problem and secure sites work again.

It seems like when the config was generated the server.php script was not correctly injected.

Steps to reproduce

1. Create a new site
2. Secure site
3. Visit the site, redirects to /xx

I've recorded a video demonstrating the issue and how to fix each instance.

Relevant log output

No response

[mpociot]

@beneverard thank you for the in-depth explanation and the video!

So when you secure a site, we get the location of the server.php file by calling osascript and run an Apple Script. And this seems to return the integer for you, which is very weird.

Could you try this:

touch script.txt
nano script.txt

Paste this content:

tell application "Herd"
    get valet path
end tell

Run the script via:

osascript scrip.txt

You should see output like this:

path:/Applications/Herd.app/Contents/Resources/valet/server.php

[beneverard]

@mpociot Ah this is all starting to make sense now, so I've run the commands above and here's my output:

2024-09-18 11:00:27.397 osascript[56801:3366338] ApplePersistence=NO
path:/Applications/Herd.app/Contents/Resources/valet/server.php

The first line I get is this notice/error (whatever it is I don't really know), and I assume in Herd you're splitting the string by the colon character and using the 2nd ([1]) element found as the path.

I did a quick test at "11:18:04" to confirm and the "random" number was "18", the minutes from the timestamp in that extra notice output.

I know others have experienced the same problem, perhaps using the "path:" string instead could make this a little more reliable.

Let me know if I can assist further and thanks for your reply and work on Herd.

[mpociot]

huh, interesting! I can't figure out how to reproduce this locally unfortunately.

Could you try and run the osascript again but this time redirect error output to /dev/null? I assume the message you get is actually coming from stderr:

osascript script.txt 2>/dev/null

[beneverard]

@mpociot When I output to /dev/null I get just the path only, so I think your assumption is correct.

path:/Applications/Herd.app/Contents/Resources/valet/server.php

[mpociot]

Nice! Thank you for verifying this! This'll be fixed in the next update 🎉

[beneverard]

Thank you, I'm glad I can help.

[mpociot]

This is now fixed in Herd 1.11.1

[beneverard]

@mpociot I'm sorry to be the bearer of bad news, but I'm still experiencing this problem.

I'm on Herd version 1.11.1 (Build: 34), and when securing sites the above issue still occurs.

I'd be happy to help perform further tasks to help get info on the problem, or to test a beta version if that'd help.

Not that I think it makes a big difference, but when I re-run the script.txt test you mentioned above the one with /dev/null continues to return the correct value with additional messages, here's a screenshot to show.

[beneverard]

Ignore the above, upgraded to "1.11.2 (Build: 35)" and this appears to be working as expected now :-)