URL's break when missing trainling slash on APP_URL #197

New Issue

OVERLORD · 2026-02-04T17:35:53+03:00

OVERLORD commented

2026-02-04 17:35:53 +03:00

Originally created by @xorander00 on GitHub (Nov 2, 2016).

Love the project. Just updated to 0.12.2. Previous version was either 0.11.2 or 0.12.0 (can't remember honestly, sorry). The previous version was running fine.

Update process was manual (git -> composer -> migrate). Tried to load the site, and the layout was messed up because the first request for the site was over HTTPS (haproxy reverse ssl-terminating proxy), but all subsequent requests (except logo.png) are over HTTP, and thus blocked. The run-down list of things I tried:

Checked Chrome console at the client for clues, but nothing came up other than the complaints about mixed-mode content being blocked.
Checked nginx config to make sure it was sending X-Forwarded-Proto, even though I don't think this project uses it.
Restarted php & nginx.
Checked .env to confirm that APP_URL is https://..., which it was fine.
Cleared all relevant caches using artisan and rebuilt anything that was necessary (precompiled classes, etc.).
Cleared redis cache.
Made sure composer libs were up-to-date as per the .lock.
Brought the site down and then up.
Double-checked migrations.
tail -f'ed the nginx & php logs while loading a request to look for any warnings/errors. There were none.

None of it worked. I'll dig into this further when I have the time, but figured I'd give it a shot here and see what's going on. Let me know if any other info is required. My service/platform environment is as follows:

For Bug Reports

PHP Version: 5.6.27

MySQL Version:
MariaDB-10.1.17

Expected Behavior:
Load content using the original request protocol scheme.

Actual Behavior:
Initial load from HTTPS, but loads content (ex: styles.css, jquery.min.js, etc.) over HTTP.

Originally created by @xorander00 on GitHub (Nov 2, 2016). Love the project. Just updated to 0.12.2. Previous version was either 0.11.2 or 0.12.0 (can't remember honestly, sorry). The previous version was running fine. Update process was manual (git -> composer -> migrate). Tried to load the site, and the layout was messed up because the first request for the site was over HTTPS (haproxy reverse ssl-terminating proxy), but all subsequent requests (except logo.png) are over HTTP, and thus blocked. The run-down list of things I tried: - Checked Chrome console at the client for clues, but nothing came up other than the complaints about mixed-mode content being blocked. - Checked nginx config to make sure it was sending X-Forwarded-Proto, even though I don't think this project uses it. - Restarted php & nginx. - Checked .env to confirm that APP_URL is https://..., which it was fine. - Cleared all relevant caches using artisan and rebuilt anything that was necessary (precompiled classes, etc.). - Cleared redis cache. - Made sure composer libs were up-to-date as per the .lock. - Brought the site down and then up. - Double-checked migrations. - tail -f'ed the nginx & php logs while loading a request to look for any warnings/errors. There were none. None of it worked. I'll dig into this further when I have the time, but figured I'd give it a shot here and see what's going on. Let me know if any other info is required. My service/platform environment is as follows: ### For Bug Reports PHP Version: 5.6.27 MySQL Version: MariaDB-10.1.17 Expected Behavior: Load content using the original request protocol scheme. Actual Behavior: Initial load from HTTPS, but loads content (ex: styles.css, jquery.min.js, etc.) over HTTP.

OVERLORD added the 🐛 Bug label 2026-02-04 17:35:53 +03:00

OVERLORD closed this issue

2026-02-04 17:35:59 +03:00

OVERLORD commented

2026-02-04 17:36:08 +03:00

@xorander00 commented on GitHub (Nov 2, 2016):

I just looked and it seems I was likely running version 0.12.1 before upgrading to 0.12.2. I saw the file date/time stamps and a majority of them are for Sep 12, which I'm pretty was the date that I did the last install/upgrade.

@xorander00 commented on GitHub (Nov 2, 2016): I just looked and it seems I was likely running version 0.12.1 before upgrading to 0.12.2. I saw the file date/time stamps and a majority of them are for Sep 12, which I'm pretty was the date that I did the last install/upgrade.

OVERLORD commented

2026-02-04 17:36:13 +03:00

@xorander00 commented on GitHub (Nov 3, 2016):

Figured it out. APP_URL requires the trailing slash.

@xorander00 commented on GitHub (Nov 3, 2016): Figured it out. APP_URL requires the trailing slash.

OVERLORD commented

2026-02-04 17:36:20 +03:00

@ssddanbrown commented on GitHub (Nov 3, 2016):

Hi @xorander00,
Sorry about this issue. I've re-opened it under a different title as I'd still like to fix this to prevent others being confused about this same issue in the future.

@ssddanbrown commented on GitHub (Nov 3, 2016): Hi @xorander00, Sorry about this issue. I've re-opened it under a different title as I'd still like to fix this to prevent others being confused about this same issue in the future.

OVERLORD commented

2026-02-04 17:36:28 +03:00

@xorander00 commented on GitHub (Nov 3, 2016):

No worries. I appreciate the project and the help.

Is the trailing slash a Laravel-specific requirement or is it specific to BookStack? I'm asking because I haven't written PHP in years and I have a couple of other projects deployed that are built on Laravel. It would be something to keep in mind for the future.

@xorander00 commented on GitHub (Nov 3, 2016): No worries. I appreciate the project and the help. Is the trailing slash a Laravel-specific requirement or is it specific to BookStack? I'm asking because I haven't written PHP in years and I have a couple of other projects deployed that are built on Laravel. It would be something to keep in mind for the future.

OVERLORD commented

2026-02-04 17:36:31 +03:00

@ssddanbrown commented on GitHub (Nov 3, 2016):

After some testing I think this issue may have been a problem in webserver configuration. It's not an issue in Laravel.

I'll close this for now unless it become a common issue then I guess we'll look into common causes & differences in configuration.

@ssddanbrown commented on GitHub (Nov 3, 2016): After some testing I think this issue may have been a problem in webserver configuration. It's not an issue in Laravel. I'll close this for now unless it become a common issue then I guess we'll look into common causes & differences in configuration.

OVERLORD commented

2026-02-04 17:36:36 +03:00

@dohlin commented on GitHub (Apr 3, 2017):

@xorander00 @ssddanbrown I just wanted to say thank you so much for updating your OP with the resolution you found - I was experiencing the exact same issue, and sure enough updating the APP_URL line to be the URL I was trying to access (https://whatever.example.com/) and including the trailing slash fixed my issue as well! To be fair this line was completely commented out on mine originally but regardless this fixed it. Thank you again!

@dohlin commented on GitHub (Apr 3, 2017): @xorander00 @ssddanbrown I just wanted to say thank you so much for updating your OP with the resolution you found - I was experiencing the exact same issue, and sure enough updating the APP_URL line to be the URL I was trying to access (https://whatever.example.com/) and including the trailing slash fixed my issue as well! To be fair this line was completely commented out on mine originally but regardless this fixed it. Thank you again!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#197