Tons of panic errors with GZIP enabled

[HorlogeSkynet]

• Gitea version (or commit ref): v1.10.0
• Git version: v2.20.1
• Operating system: Debian Buster
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: https://pastebin.com/48z5b0FL

Description

Hey everyone !
It seems like there has been some issues with GZIP for some minor versions from now.
I can't really figure out since when, as logs have been polluted and rotated for weeks.
The error attached above is thrown every ~20 seconds when GZIP is enabled on my setup.
Still happening against v1.9.6 and v1.10.0 .

I can provide further details if you guys got some ideas to narrow down the diagnostic.

Bye, thanks 👋

[zeripath]

Ok. We need the precise version of Gitea. routers/repo/repo.go appears to be one of the more active parts of our code so line 342 isn't too helpful.

Do you have a SHA hash for the commit that made those logs?

[zeripath]

It would also be helpful to see the router logs and surrounding logging

[zeripath]

Assuming that 1.10 produced that log the implication is that this caused the panic:

gitea/routers/repo/repo.go

Line 342 in 9619ccf

err = models.StarRepo(ctx.User.ID, ctx.Repo.Repository.ID, true)

Which doesn't exactly make a lot of sense

[zeripath]

Basically either ctx.User is nil or ctx.Repo.Repository / ctx.Repo is nil.

[zeripath]

Assuming that is the causative line, repo.Action matches the following endpoint:

gitea/routers/routes/routes.go

Line 684 in 9619ccf

m.Get("/:username/:reponame/action/:action", reqSignIn, context.RepoAssignment(), context.UnitTypes(), repo.Action)

[zeripath]

Which sort of implies that you're try to star a repository but why would you be doing that so often... It's weird.

[HorlogeSkynet]

It's definitely v1.10.0 .
It looks like my instance is being hard-crawled (so huge amount of unauthenticated requests) for some days now (🤷‍♂).

By increasing the log level, I've managed to reproduce the error on my own.
It appears when requesting something like : https://$HOSTNAME/$OWNER/$REPOSITORY/action/watch?redirect_to=$URL_ENCODED_FILE_LOCATION.
Symmetrically, as you pointed out, trying to star is equivalent.
Errors come up, but the back-end correctly redirects to the authentication page.

So, is it just about a null-able variable being used somewhere ?

Thanks for the quick feedback @zeripath 🙇

EDIT (important) : With GZIP disabled, I still cannot reproduce the behavior.

[zeripath]

It's weird it's like things are not being cancelled when the user is denied - I'll have to take a look.

[zeripath]

Ah damn... When I reimplemented this I just copied the behaviour that was there before...

it was wrong then and it is wrong now.

We need to actually properly implement all the context response writer methods - or - change the internal writer of the context response writer.