starred/shiori

Fork 0

mirror of https://github.com/go-shiori/shiori.git synced 2026-04-25 06:25:54 +03:00

[GH-ISSUE #1109] --webroot flag not working with v1.7.4 #461

New issue

Open

opened 2026-02-25 23:34:16 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 23:34:16 +03:00

Owner

Originally created by @LordEidi on GitHub (May 30, 2025).
Original GitHub issue: https://github.com/go-shiori/shiori/issues/1109

Data

Shiori version: 1.7.4
Database Engine: SQLite
Operating system: Debian stable
CLI/Web interface/Web Extension: Web Interface

Describe the bug / actual behavior

Today, I tried to update my instance of shiori. My instance used to run behind an instance of nginx and finely served pages as expected.

During the update process, I changed my flags from

./shiori serve --webroot /shiori --portable

./shiori server --webroot /shiori --portable

as mentioned in the logs.

After updating the binary to v1.7.4, the reverse proxy setup does not work anymore. I get 404 errors in the log like this:

method=GET path=/shiori/login/ referer= statusCode=404

I then exposed the webserver with the flag --address 0.0.0.0 and tried to use curl and to access the shiori instance from a different machine directly (without going through the reverse proxy).

This works (login page is served):

curl http://mysite:8080/

This does not (404):

curl http://mysite:8080/shiori/

So it seems, that Shiori does not respect / use the --webroot flag on the latest version.

Expected behavior

I expect Shiori to serve pages under the --webroot flag, namely (in my example) under:

curl http://mysite:8080/shiori/

I would also expect the served login page to rewrite the API URL respecting the --webroot flag. But I find this line in the served login content:

const response = await fetch(new URL("api/v1/auth/me", document.baseURI), {

Which IMHO is wrong as well, it should have the --webroot flag in front of the URL.

To Reproduce

Download the latest package from here https://github.com/go-shiori/shiori/releases/tag/v1.7.4
Unpack the content
Run Shiori with these flags:

./shiori server --webroot /shiori --portable

and try to access it with

curl http://127.0.0.1:8080/shiori/

Originally created by @LordEidi on GitHub (May 30, 2025). Original GitHub issue: https://github.com/go-shiori/shiori/issues/1109 ## Data - **Shiori version**: 1.7.4 - **Database Engine**: SQLite - **Operating system**: Debian stable - **CLI/Web interface/Web Extension**: Web Interface ## Describe the bug / actual behavior Today, I tried to update my instance of shiori. My instance used to run behind an instance of nginx and finely served pages as expected. During the update process, I changed my flags from `./shiori serve --webroot /shiori --portable` to `./shiori server --webroot /shiori --portable` as mentioned in the logs. After updating the binary to v1.7.4, the reverse proxy setup does not work anymore. I get 404 errors in the log like this: `method=GET path=/shiori/login/ referer= statusCode=404` I then exposed the webserver with the flag --address 0.0.0.0 and tried to use curl and to access the shiori instance from a different machine directly (without going through the reverse proxy). This works (login page is served): `curl http://mysite:8080/` This does not (404): `curl http://mysite:8080/shiori/` So it seems, that Shiori does not respect / use the --webroot flag on the latest version. ## Expected behavior I expect Shiori to serve pages under the --webroot flag, namely (in my example) under: `curl http://mysite:8080/shiori/` I would also expect the served login page to rewrite the API URL respecting the --webroot flag. But I find this line in the served login content: `const response = await fetch(new URL("api/v1/auth/me", document.baseURI), {` Which IMHO is wrong as well, it should have the --webroot flag in front of the URL. ## To Reproduce - Download the latest package from here [https://github.com/go-shiori/shiori/releases/tag/v1.7.4](https://github.com/go-shiori/shiori/releases/tag/v1.7.4) - Unpack the content - Run Shiori with these flags: `./shiori server --webroot /shiori --portable` - and try to access it with `curl http://127.0.0.1:8080/shiori/`

kerem added the

type:bug

label

2026-02-25 23:34:16 +03:00

kerem commented

2026-02-25 23:34:17 +03:00

Author

Owner

@lawrencecandilas commented on GitHub (Jun 20, 2025):

I had this issue, but eventually got it working. I use nginx as a reverse proxy.

Command line I'm using to launch shiori
/opt/shiori/shiori server --address "[fc00::XXX:X]" --port XXXXX --webroot /dir/dir2/dir3/

Working Nginx config:

location /dir/dir2/dir3/ {
# proxy_pass MUST have a trailing slash
 proxy_pass http://[fc00::XXX:X]:XXXXX/; # trailing slash
 proxy_http_version 1.1;
 proxy_buffering off;
}

I upgraded from 1.5.X and I had to alter the nginx config, but it is working with the above.

My older config that worked on 1.5.X but stopped working looked like this:

location ^~ /dir/dir2/dir3/ {
 proxy_pass http://[fc00::XXX:X]:XXXXX; # no trailing slash
 proxy_http_version 1.1;
 proxy_buffering off;
}

@lawrencecandilas commented on GitHub (Jun 20, 2025): I had this issue, but eventually got it working. I use nginx as a reverse proxy. Command line I'm using to launch shiori `/opt/shiori/shiori server --address "[fc00::XXX:X]" --port XXXXX --webroot /dir/dir2/dir3/` Working Nginx config: ``` location /dir/dir2/dir3/ { # proxy_pass MUST have a trailing slash proxy_pass http://[fc00::XXX:X]:XXXXX/; # trailing slash proxy_http_version 1.1; proxy_buffering off; } ``` I upgraded from 1.5.X and I had to alter the nginx config, but it is working with the above. My older config that worked on 1.5.X but stopped working looked like this: ``` location ^~ /dir/dir2/dir3/ { proxy_pass http://[fc00::XXX:X]:XXXXX; # no trailing slash proxy_http_version 1.1; proxy_buffering off; } ```

kerem commented

2026-02-25 23:34:17 +03:00

Author

Owner

@Australis86 commented on GitHub (Jun 27, 2025):

@LordEidi - I think #1121 should address this. In my usage case the --webroot option does appear to be respected, but I had to add the trailing / to get it to work, e.g.

./shiori server --webroot /shiori/

@Australis86 commented on GitHub (Jun 27, 2025): @LordEidi - I think #1121 should address this. In my usage case the --webroot option does appear to be respected, but I had to add the trailing / to get it to work, e.g. `./shiori server --webroot /shiori/`