gitea/gitea:latest Docker image redirects everything with 302 to /

[kamulos]

All images and style-sheets are redirected to / with HTTP 302 (For example http://localhost:3000/img/loading.png to http://localhost:3000/ in my case).

working:

docker run --rm -it -p3000:3000 gitea/gitea:1.12.6

broken:

docker run --rm -it -p3000:3000 gitea/gitea:latest

[pecastro]

+1

[zeripath]

The CSS changed a lot between 1.12 and 1.13 - could you double check that you don't have the old one cached. Ctrl-f5 stuff. That's usually the problem.

Next thing check if you're using custom templates and if so - make sure they're up to date.

Give us some information about your app.ini eg if you're using static root path, a subpathor the like.

Also olease use the issue template we provided. Master moves a lot so the sha reference is also helpful and if you could give us some logs that's also really helpful.

[kamulos]

From Docker hub:

gitea/gitea:latest (broken):
sha256:0facddc4a9a1e384db5edb0a3586aa55d80a48a000a068c5864f25628c347727

gitea/gitea:1.12.6 (working):
sha256:e17222b92531fc0498c962e54e0ba7ecfe3b0492b8c8c25a779c48cdeb5e3eb7

From docker images:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
gitea/gitea         latest              64809342a78b        4 hours ago         149MB
gitea/gitea         1.12.6              953c07b84f30        11 days ago         143MB

Is the issue not reproducible with the command lines above?

• This is not a caching issue. The server returns 302 to an unreasonable destination, when I run gitea:latest. This is not the case when I run gitea:1.12.6
• I have no custom template, I am using a fresh and untouched docker container and destroy it as soon as I stop the server
• I did not touch the app.ini . In fact this was the first time I started gitea. Everything is in the default config of the container (SQLite, listening on port 3000 etc)
• Which logs can I give you?

This is literally an untouched docker container, which should be easy to reproduce and have the same behaivor on every machine. I am sure that this is not only a problem on my machine because the second poster agreed with me.

Please tell me if you need more information.

[shilch]

I ran into this redirect issue recently as well:

$ curl --head http://localhost:3000/css/index.css\?v\=759b74ce43947f5f4c91aeddc3e5bad3
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: http://localhost:3000/
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gitea=8c39ec8a7b469e83; Path=/; HttpOnly
Set-Cookie: _csrf=_xTnXq5hXbfq9vPESFmYZH9lq8s6MTYwNjU3MDM3NjAwOTIwMTAwMA; Path=/; Expires=Sun, 29 Nov 2020 13:32:56 GMT; HttpOnly
X-Frame-Options: SAMEORIGIN
Date: Sat, 28 Nov 2020 13:32:56 GMT

I don't have any issues when building and running the tag v1.12.6.

[lunny]

The bug should be related with installation page but not related non-install pages.

[shilch]

@lunny git bisect revealed that the bug was introduced by the following commit:

c296f4fed66288431fa7ec3a64f990beccd29eb1 is the first bad commit
commit c296f4fed66288431fa7ec3a64f990beccd29eb1
Author: Lunny Xiao <xiaolunwen@gmail.com>
Date:   Fri Nov 13 20:51:07 2020 +0800

    Introduce go chi web framework as frontend of macaron, so that we can move routes from macaron to chi step by step (#7420)

    * When route cannot be found on chi, go to macaron

    * Stick chi version to 1.5.0

    * Follow router log setting

:100644 100644 95ad5f308a5e99399ea38cb19f30a96e07a2829e b0e652bb6fb75fef4cd01cc25c85e031c5c8e899 M	.golangci.yml
:040000 040000 4f6d9d2c4c31944e367ce69f18cff53cf5adcd12 ce5c8d216dca28f5af90b2b72ebc5ee99ef83e73 M	cmd
:040000 040000 6ae0f10316e68839504218123d2de6bcc2ff7841 b7b0521533f37caaf27c68acb8885c461a8c159f M	contrib
:100644 100644 d7e8edc1050bf29c5cf946a8e5a3a3d6fef3a7af e9a264fdfdf1807412cf5a43e7c5bd3cb0447a13 M	go.mod
:100644 100644 7710cbc63f5a2d91b04e5bc1c70d805991a2d6b6 c169da1c76157e9e1982efa138b92495417e965c M	go.sum
:040000 040000 3753d495032c2afec048fe4f65aa538c8e3e7250 7841ec617db0b1a29935fbc9875454ada58d123d M	integrations
:040000 040000 94e4ac5fc00ab7dc1335e0728644a04c40d18f46 e03b2f1ceefad7de6247e8f59ef2a253f38fc37c M	modules
:040000 040000 14d0d542812102568aece741e2a3a249e8967b1a 31683d11a13c328c89af396f8ed925d0e7218051 M	routers
:040000 040000 b773df96cdbfa5c3d765e1ce99ac11464536ad03 c35d9a56973defcc128fdeef9c38376e5b50ced6 M	vendor

[lunny]

Found the bug from the chi's source codes. If there is no any handler defined but only middlewares, then all middlewares will be ignored. So I have to define one handler for install routes.

func (mx *Mux) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	// Ensure the mux has some routes defined on the mux
	if mx.handler == nil {
		mx.NotFoundHandler().ServeHTTP(w, r)
		return
	}

[shilch]

Oh, it's actually an issue in chi?

[shilch]

Works:

diff --git a/routers/routes/chi.go b/routers/routes/chi.go
index 5ff7a728f..00689441b 100644
--- a/routers/routes/chi.go
+++ b/routers/routes/chi.go
@@ -230,6 +230,12 @@ func RegisterInstallRoute(c chi.Router) {
 	m := NewMacaron()
 	RegisterMacaronInstallRoute(m)
 
+	// We need at least one handler in chi so that it does not drop
+	// our middleware: https://github.com/go-gitea/gitea/issues/13725#issuecomment-735244395
+	c.Get("/", func(w http.ResponseWriter, req *http.Request) {
+		m.ServeHTTP(w, req)
+	})
+
 	c.NotFound(func(w http.ResponseWriter, req *http.Request) {
 		m.ServeHTTP(w, req)
 	})

[lunny]

@shilch Could you send a patch to Gitea?

[shilch]

I'll do