Gitea should set `Cache-Control: public` (or unset) on raw files in public repositories so reverse proxies can cache properly.

[ledlamp]

Description

So it appears that Gitea always sets Cache-Control: private, max-age=300 on raw files, even if the asset is in a public repository and ought to be cachable by a reverse proxy.

This means that if you want to cache gitea right now, you have to override this, but then you'll expose files in private repositories since the proxy can't tell the difference.

It also appears that Gitea disables caching on HTML renders (no-store), which makes sense, but it might be a good idea to allow caching of those for unauthenticated visitors, since some views may not change frequently, but could have heavy traffic from unauthenticated visitors (think wikis and readmes with embedded images, etc).

Also, why does Gitea always set a cookie, even if you're not logged in? This is also problematic for caching; Cloudflare won't cache any response with a cookie for example. And since it appears the same i_like_gitea cookie is used for both guest sessions and logged in users, there is no way for a custom reverse proxy to tell the difference between visitors and logged-in users.

To the eyes of a reverse proxy, with these two issues, everyone is logged in, and nothing is cacheable!

Gitea Version

1.17.2, 1.18.0+dev-518-ga813c9d8f

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

N/A; checked response headers of raw file responses on gitea.moe and try.gitea.io.

Database

SQLite

[delvh]

Erm… I don't think it is a good idea to cache user-specific responses on a CDN or reverse-proxy.
Basically, whenever you request any page content, it will be customized for the current user.
This should even be true for API requests as they need to validate that the user is allowed see the response.

[ledlamp]

Erm… I don't think it is a good idea to cache user-specific responses on a CDN or reverse-proxy. Basically, whenever you request page content, it will be customized for the current user. This should even be true for API requests as they need to validate that the user is allowed see the response.

Of course, you don't do that! But the raw files in a public repository are not "user-specific" responses, and being able to cache them would be very helpful.

[ledlamp]

Things that should be cachable (Cache-Control: public or not set, and no cookies):

• Raw files/assets/media in public repositories
• HTML renders of not-logged-in visitors (even if the cache should be short-lived)

Things that must NOT be cachable (Cache-Control: private, cookies required):

• Raw files/etc in private repositories
• Any HTML render for a logged-in user

Gitea is an ideal candidate for caching/CDN since you might use it to publish projects/wikis/files etc to the general public (so most views would be from unregistered visitors). But putting it behind Cloudflare won't do anything, due to the improper use of cache-control and cookies.

[wxiaoguang]

Theoretically, yes

In fact, it's very difficult to make every cache header that correct at the moment. It needs a lot of work, needs to be fine-tuned and tested very carefully.

[delvh]

And the problem I can see:
Even on public repos, you still have user-specific content, like the notifications, who is logged in, …
The only solution where this would work is for unauthenticated users as the response looks always the same then.
But that's a lot of work for probably minimal gain.
How often do you browse a Gitea instance without being logged in?

[silverwind]

HTML content should never be cached by Gitea itself, even for unauthenticated users. Things like relative timestamps will change. Of course reverse proxies can override those cache headers if they so desire, but they will be serving stale content.

[ledlamp]

HTML content should never be cached by Gitea itself, even for unauthenticated users. Things like relative timestamps will change. Of course reverse proxies can override those cache headers if they so desire, but they will be serving stale content.

I never said Gitea itself should cache anything. Gitea should just follow the standard and provide correct semantic information for the proxy. You can't make a proxy cache anything without leaking private files because gitea says everything is private!

And even a few second cache on html could be helpful against DoS. It is up to the webmaster to decide how they want to cache.

How often do you browse a Gitea instance without being logged in?

Don't tell me I'm the only one who uses Gitea to publish stuff to the public. 90% of requests are unauthenticated visitors.

[ledlamp]

Theoretically, yes

In fact, it's very difficult to make every cache header that correct at the moment. It needs a lot of work, needs to be fine-tuned and tested very carefully.

if ctx.Repo.Repository.IsPrivate is false, remove "private" directive. You could make private default but add an argument to AddCacheControlToHeader to explicitly make it public, then add that logic in the thing that serves the raw files.

[shyim]

How do you want to do then cache invalidation? When you link to a branch and the branch gets updated still the old content is maybe shown as the response was cache-control public

[Saklad5]

User-specific content should use Cache-Control: private. You almost never need to set this explicitly, as the default behavior is to treat a response to a request with an Authorization header as private unless explicitly marked public.

Conversely, any content that is not user-specific or otherwise private despite being requested with an Authorization header should use Cache-Control: public.

Every single response should have a Cache-Control header and ideally an ETag. Anything static with some form of versioning in the URI, particularly with commit hashes, should use Cache-Control: immutable.

Cache-Control: no-store should be used very sparingly. Something unsafe to reuse is almost always better off with Cache-Control: no-cache, though even that should only be specified for a good reason. With static files, I personally tend to default to Cache-Control: max-age=86400;stale-while-revalidate=518400.

Keep in mind that most user-agents will set Cache-Control: no-cache in the request if the user manually reloads a page.

Gitea should not worry about actually caching things. However, only it is positioned to intelligently determine what is safe to cache, and it needs to pass that along.