Gitea incorrectly applies STATIC_URL_PREFIX when loading JS files

[clarfonthey]

Gitea Version

1.15.7

Git Version

2.34.1

Operating System

Arch Linux

How are you running Gitea?

I'm using the Arch Linux package for gitea and reverse-proxying via nginx.

Database

PostgreSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

I have gitea hosted at the URL https://vc.ltdk.xyz, and a STATIC_URL_PREFIX at https://ht.ltdk.xyz/gitea/.

When loading tribute.js, it appears that gitea is somehow combining these two URLs into something that doesn't work, trying to load https://vc.ltdk.xyz/gitea/assets/js/tribute.js when the real URL is https://vc.ltdk.xyz/assets/js/tribute.js (note the lack of gitea/).

I also have STATIC_ROOT_PATH set to ./ if that matters at all -- I'm not exactly sure what this option is.

If you'd like to view this problem live, the URL https://vc.ltdk.xyz/cli/viro/issues/4 seems to also have this problem when loading when not logged in. I tried going through the JS stack trace and just gave up since webpack doesn't really offer source maps for the actual file loading, and I have a feeling it's something messed up in there. If there's any particular thing I can do to make debugging easier, let me know and I can offer it.

Side note -- this completely prevents properly editing issues since there is no alternative to the JS-based editor, at least as far as I'm aware.

I also don't think upgrading to 1.15.8 would actually fix the problem since the changelog mentions nothing that could potentially change the behaviour, but if you do think that it would help, I can look into upgrading gitea manually and try that.

Screenshots

No response

[wxiaoguang]

1. Show your nginx/gitea config, and please follow the document https://docs.gitea.io/en-us/reverse-proxies/#nginx-with-a-sub-path
2. Maybe the only thing you need is to set ROOT_URL (with a correct nginx config), remove other *_URL / *_PATH options.

[clarfonthey]

I think you misunderstood; the Gitea config is not at a subpath at all:

  server_name vc.ltdk.xyz;
  location / {
    proxy_pass http://unix:/run/gitea/gitea.sock;
    proxy_redirect off;
    proxy_set_header "Host" $host;
    proxy_set_header "X-Forwarded-For" $proxy_add_x_forwarded_for;
  }

The static files for gitea are stored at a subpath, but that's just a subpath of a directory. Literally:

  server_name ht.ltdk.xyz;
  root /srv/http/ht;
  index index.htm index.html;
  location / {
    try_files $uri $uri/ =404;
  }

with the static files for gitea stored in /srv/http/ht/gitea.

For full clarification of the various app.ini variables:

ROOT_URL = https://vc.ltdk.xyz/
STATIC_URL_PREFIX = https://ht.ltdk.xyz/gitea/
STATIC_ROOT_PATH = ./

And as I mentioned, static files do work (CSS, images, etc.); it's just that this one JS file isn't being loaded correctly. I've also managed to get this working in the past, and I don't know if 1.15.7 specifically broke it or if it broke in a previous version and I didn't realise until now.

[wxiaoguang]

I see your problem. The key problem might be here:

gitea/web_src/js/features/tribute.js

Line 65 in d2fac63

const {default: Tribute} = await import(/* webpackChunkName: "tribute" */'tributejs');

That index.js is likely loading another JS (tribute.js) in a relative path from current domain. So at the moment you could not mix sub-path and non-sub-path together.

And I would mention @silverwind to consult if my understanding is correct / if it's possible to get other solutions or refactoring.

[clarfonthey]

Thanks for helping out with this. I honestly have no idea how to debug weird webpack problems like this, so, hopefully someone can get to the bottom of this.

If someone with a bit more knowledge on this is having trouble replicating it, I might have a ZFS snapshot back from the time when it did work and could do some bisection work, but at least for the moment I'd like to try and avoid that if someone does know how to fix this easily.

[zeripath]

Could you check on main/1.16 to see if this is still a problem there?

[clarfonthey]

I'm going to try updating to 1.15.9 first just to make sure it isn't fixed there either, but will keep updated on what happens.

[clarfonthey]

(Update on this, it still fails on 1.15.11, but I haven't updated to 1.16 yet to test. Will close if 1.16 changes fixed this.)

[wxiaoguang]

That index.js is likely loading another JS (tribute.js) in a relative path from current domain. So at the moment you could not mix sub-path and non-sub-path together.

I didn't see related PRs, so it's likely the issue is still the same (until someone submits a correct PR).

[clarfonthey]

So, I discovered my actual problem. I sort of assumed that gitea embedded extract would just put the files in the format expected by gitea, but I was wrong; the files in the public folder need to be sent to an assets folder in order for this to work. I'm not sure why this assets suffix is added to URLs, but it seems to mess things up.

I had earlier set things up and I guess just renamed the directory, so, when I re-extracted on update, it never actually used the up-to-date JS. This probably explains a lot of my problems.

I'm going to close this issue but search later to figure out what can be done to make this more clear.

[wxiaoguang]

Glad to hear that it's resolved.

Since 1.17 , if there are JS errors, you will see a prompt on the web UI, so it will prevent some problems.

[KB3HNS]

I am experiencing the exact same problem on 1.17.3 (latest) see issue 21845