Support resizing of local avatars

[somera]

Description

When I see the size=84 parameter in the URL I think gitea should send 84x84 pixel big icon. But I see, that Gitea is sending 290x290 pixel big icon.

With 2000+ organizations it's need ~10 seconds, 2000+ requests and some MB's.

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.25.1

Operating System

Ubuntu 20.04.4

How are you running Gitea?

Self hosted gitea-1.17.1-linux-amd64

Database

PostgreSQL

[silverwind]

Yes, seems like a bug. The intention is for the server to send 84px in this case.

[somera]

A can't compare this to the 1.16.x version. But in the 1.16.x release loading a page with a lot of orgas war faster. Looks like new bug in 1.17.x.

[lunny]

But they will be cached?

[somera]

But they will be cached?

Yes. But this is "strange". When I click in gitea I see "memory cached" and its fast.

When I try to migrate new project it slower (8-10 seconds) and I see "disk cache".

Tested with Chrome (Version 104.0.5112.102 (Offizieller Build) (64-Bit))

[silverwind]

Not sure when a browser will decide to offload to disk, but we should probably make the hardcoded 5 minute cache duration on avatars configurable:

gitea/routers/web/user/avatar.go

Lines 18 to 21 in dc0253b

	// here we should not use `setting.StaticCacheTime`, it is pretty long (default: 6 hours)
	// we must make sure the redirection cache time is short enough, otherwise a user won't see the updated avatar in 6 hours
	// it's OK to make the cache time short, it is only a redirection, and doesn't cost much to make a new request
	httpcache.AddCacheControlToHeader(ctx.Resp.Header(), 5*time.Minute)

[silverwind]

#20958 restores avatars to use STATIC_CACHE_TIME again which defaults to 6h so we can hit the cache much more than before. Turns out it wasn't needed.

[silverwind]

Back to this issue's topic: The problem is that the size argument only works for external avatar services like Gravatar. The local avatar handler ignores the size argument and always serves the full-size avatar from storage.

What needs to be done:

1. Make the /avatars/* request handler respect size and resize it.
2. Store the resulting images in server cache and invalidate this cache when a user/org updates their avatar.

(Can someone rename issue to "Support resizing of local avatars"? I can't)

[somera]

@silverwind I renamed it

[somera]

Will be there a fix for the next (1.17.3 or 1.18.x) release?

[somera]

Status with 1.17.2 for the start page with 2192 organisations.

Chrome:

FF: