Fix incorrect cookie path for AppSubURL

[wxiaoguang]

Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Regression of #24107 : at that time, I was misled by the comment Cookie path to store. Default is "/": because when AppSubURL is empty, the cookie path is not defaulted to "/". So I added a slash there. But when there is a sub path, the extra slash is wrong.

[OdinVex]

How would this fix #29533? That BR mentions all the other links are fine, only pagination is broken because of a missing slash in it alone.

Edit: The cookie thing might be one issue but I'm talking about the pagination being an issue. They need a slash, the link generation sections...

[wxiaoguang]

How would this fix #29533? That BR mentions all the other links are fine, only pagination is broken because of a missing slash in it alone.

#29533 (comment)

[OdinVex]

How would this fix #29533? That BR mentions all the other links are fine, only pagination is broken because of a missing slash in it alone.

#29533 (comment)

See updated edit. The cookie thing might be a problem but I'm talking about another issue, pagination.

[wxiaoguang]

See updated edit. The cookie thing might be a problem but I'm talking about another issue, pagination.

I think there are 2 problems:

1. Unable to click the links in pagination, incorrect cooke path leads to invalid session (logout)
2. The URL generation in pagination

This PR's purpose is to fix the first one: make end users could use subpath correctly.

For the second one, at the moment I didn't see a easy&clear fix for it. If the generated URLs don't affect daily use, I think we could have more time to do a big refactoring in the future to figure out how to handle the "$.Link" properly. Because the "Link" is just used this way widely, and "paginate.tmpl" is a general template used by many pages, not only for the home page (dashboard).

[OdinVex]

The URL generation in pagination

Yes, there is an issue in the URL generation, the lack of a forward-slash and it appears to only affect the user dashboard itself at a quick glance. I checked the Instance in repo issues and those generate correct links. This appears isolated to the user dashboard.

[wxiaoguang]

The URL generation in pagination

Yes, there is an issue in the URL generation, the lack of a forward-slash and it appears to only affect the user dashboard itself at a quick glance. I checked the Instance in repo issues and those generate correct links. This appears isolated to the user dashboard.

Gitea itself never adds trailing slash (update: to the full paths). If you see trailing slashes (in the full paths), are they added by your reverse proxy?

[OdinVex]

Gitea itself never adds trailing slash. If you see trailing slashes, are they added by your reverse proxy?

We're not talking about a trailing forward-slash.

Gitea adds the forward-slash after SUBPATH on everything else, just not pagination. They are not added by my proxy, it's Apache with no content-editing at all.

Example:

<a href="/SUBPATH/assets/licenses.txt">Licenses</a>
<a href="/SUBPATH/api/swagger">API</a>

That's in the actual source on every page (browser, view source). Only the dashboard's pagination is broken. Every other page appears fine and with a forward-slash correctly after SUBPATH.

[wxiaoguang]

I see your point. The real problem is how Gitea uses the "SUBPATH".

Gitea requires that "SUBPATH" doesn't have a trailing slash, because it is widely used like this: "{SUBPATH}/other-path". They are just hare-coded in many places, and not easy to change.

The definition is:

So at the moment, we can't simply change its definition or behavior. That's what I meant in #29534 (comment)

For the second one, at the moment I didn't see a easy&clear fix for it. If the generated URLs don't affect daily use, I think we could have more time to do a big refactoring in the future to figure out how to handle the "$.Link" properly. Because the "Link" is just used this way widely, and "paginate.tmpl" is a general template used by many pages, not only for the home page (dashboard).

[OdinVex]

It does affect daily use but it's somewhat minor. Users simply can't go backward or forward in their dashboard history without editing the URL themselves.

Edit: Perhaps the refactoring should simply have every link not add a forward-slash and have everyone end their SUBPATH in forward-slash (or append if missing). That might be the easiest way to refactor, but it's probably a major revision rather than minor given some parsers out there might need updating and such.

[wxiaoguang]

It does affect daily use but it's somewhat minor. Users simply can't go backward or forward in their dashboard history without editing the URL themselves.

Could you elaborate? What's wrong happens in this case if a user go backward or forward?

By design: https://host/gitea should work the same as https://host/gitea/, no matter whether there is a trailing slash.

[OdinVex]

It does affect daily use but it's somewhat minor. Users simply can't go backward or forward in their dashboard history without editing the URL themselves.

Could you elaborate? What's wrong happens in this case if a user go backward or forward?

By design: https://host/gitea should work the same as https://host/gitea/, no matter whether there is a trailing slash.

/gitea would be a file, /gitea/ would be a subpath. Servers should treat those correctly as such, that's standard. If there is no file by the same name then it could default to a directory, but the cookie issue just redirects them to the login page (no way around it unless a user adjusts the URL).

[wxiaoguang]

/gitea would be a file, /gitea/ would be a subpath. Servers should treat those correctly as such, that's standard. If there is no file by the same name then it could default to a directory, but the cookie issue just redirects them to the login page (no way around it unless a user adjusts the URL).

But for modern web servers, they never serve /gitea and /gitea/ for different purposes. It is just a "proxy path" to the backend.

For the "cookie issue", that's what we are fixing now. According to MDN: it is right to use "/subpath" as cookie path, and that's what Gitea's old code did. After the fix, everything just works fine.

[OdinVex]

But for modern web servers, they never serve /gitea and /gitea/ for different purposes. It is just a "proxy path" to the backend.

They are different, one is a file and the other is a directory. Modern web servers respect that. I've double-checked it with an Ubuntu server running Apache. They've respected the differentiation since at least 2004. Edit: If there is no file called 'gitea' it will assume you meant to use the directory but the backend must be able to understand that (Gitea does, but not the cookie logic, that is what you found). Regardless, the issue of pagination is the only one I'm concerned with.

[wxiaoguang]

But for modern web servers, they never serve /gitea and /gitea/ for different purposes. It is just a "proxy path" to the backend.

They are different, one is a file and the other is a directory. Modern web servers respect that. I've double-checked it with an Ubuntu server running Apache. They've respected the differentiation since at least 2004. Edit: If there is no file called 'gitea' it will assume you meant to use the directory but the backend must be able to understand that (Gitea does, but not the cookie logic, that is what you found). Regardless, the issue of pagination is the only one I'm concerned with.

I mean when you configure the "proxy pass" for Gitea, they never serve /gitea and /gitea/ for different purposes. It is just a "proxy path". I think it is off-topic in this PR to discuss how to configure subpath for Gitea, but indeed it is well-documented. It must configure "/gitea" to work with "/gitea/". The whole system was designed to work this way long time ago. And TBH, I don't see a real requirement for end users to make "/gitea" and "/gitea/" work differently.

https://docs.gitea.com/administration/reverse-proxies#apache-httpd-with-a-sub-path

[OdinVex]

Respectfully, I don't care what Gitea practices regarding files versus directories, that's a matter for RFC specs and I'm sticking to them for standards. Agreed it's off-topic, so I won't bother replying about it.