Avatar caching doesn't work on Firefox

[seadra]

• Gitea version (or commit ref): 1.15.2
• Git version: 2.20.1
• Operating system: Debian
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes
  • No
• Log gist:

Description

Avatar images aren't cached with Firefox, a new copy is always fetched on load.

On Chromium, it shows that avatar images are cached (in memory).

Screenshots

On Firefox, after a refresh:

[wxiaoguang]

What you saw in Firefox network log:

1. Firefox tried to get an avatar from try.gitea.io
2. try.gitea.io made a response 302 to redirect to gravatar.com (a common avatar service), because these avatars are from gravatar.
3. Firefox made a request to gravatar.com with local cache information
4. gravatar.com made a response 304 (Not Modified) to tell Firefox use local cache.

It seems there is no problem. If you believe you found a bug, just provide the expected behavior you thought it should be.

[lunny]

Have you opened the option of firefox to disable all cache?

[silverwind]

The 302 from gitea is uncachable, we might be able to make it cachable by using 308 or 301, just need to ensure that browsers will eventually invalidate that cache.

[wxiaoguang]

307 is very similar to 302 (except how to handle GET/POST methods), they all have cache control: https://stackoverflow.com/questions/12212839/how-long-is-a-302-redirect-saved-in-browser : It shouldn't be cached at all unless there's also a Cache-Control or Expires header returned by the web server. According to RFC 2616, section 10.3.3 302 Found.

And I do not think 301/308 is a correct way: https://stackoverflow.com/questions/9130422/how-long-do-browsers-cache-http-301s . The redirection may change: https://github.com/go-gitea/gitea/blob/main/routers/web/user/avatar.go#L76

From the screenshots that the author provided, I do not think there is a serious problem.

[silverwind]

I meant 308, basically any "permanent" redirect should be cachable. Edited my comment above.

I think browser should honor caching headers fine on such redirects, so they should eventually invalidate.

The browsers still honor the Cache-Control and Expires headers like with any other response, if they are specified.

[wxiaoguang]

What's the difference between 301/308 and 302/307 if they both have cache control?

[silverwind]

There's probably no difference, browsers should cache all status codes as long as cache-control headers are in place. We do not set any so the current 302 with no cache-control headers is uncachable. It might have been if it were a 301/308. I think we just need to set cache headers on redirect responses like we already do on self-hosted avatars.

[wxiaoguang]

From the above information and my test (on try.gitea.io and my private server), I do not think this is a gitea problem.

Without the cache control header in 302 response, the response is still very quick. It can not cause the problem "20 seconds lag" described by the deleted comment. Even if we add the cache control, this author's problem can't be resolved.

And the author just deleted the comment containing screenshots of his private server, you can refer that in email inbox (maybe some wrong configuration on the private server?)

[wxiaoguang]

There's probably no difference, browsers should cache all status codes as long as cache-control headers are in place. We do not set any so the current 302 with no cache-control headers is uncachable. It might have been if it were a 301/308. I think we just need to set cache headers on redirect responses like we already do on self-hosted avatars.

ps: if we add a cache control header in avatar's 302 response to reduce browser requests and reduce gitea server/database load, it would be helpful in other ways. LOL.

[silverwind]

Yes, I think it's good practice to always set cache-control. We can use time-based cache for avatar requests, e.g.

gitea/modules/httpcache/httpcache.go

Line 34 in 0767fe0

func HandleTimeCache(req *http.Request, w http.ResponseWriter, fi os.FileInfo) (handled bool) {

[silverwind]

Caching of Avatar requests certainly works in Firefox. What does not work is the caching of the redirection response in case the Avatar is hosted externally. I did add cache headers to those redirects in #16973 but Firefox just seems to ignore them. I think this is the best we can do, unless someone has another idea.

[6543]

#16973 got merged 🚀

[silverwind]

Can't figure out why Firefox would not cache those redirects, maybe it has something to do with their privacy protection, I'm not sure. Couldn't find anything on Bugzilla either.

It might be possible to directly render gravatar links without going through a redirect, but I think that method may not be possible for other federated avatar sources.

[wxiaoguang]

If the cache of avatars responded by Gitea doesn't work (described in the original issue by author, on the private server), maybe it is caused by RUN_MODE != 'prod'

gitea/modules/httpcache/httpcache.go

Line 21 in ab77a24

if !setting.IsProd() {

	if !setting.IsProd() {
		return "no-store"
	}

[silverwind]

No, I am running RUN_MODE = prod in my development setup to to specifically allow cache testing.

[wxiaoguang]

(I mean the original problem described in this issue by the author. And the fix and the original problem seems off-topic now .... )

[silverwind]

Yeah I think we can close this. OP has deleted any helpful information and is probably not going to respond any more.