Add Cache-Control header to html and api responses, add no-transform

[silverwind]

no-transform allegedly disables CloudFlare auto-minify and we did not set caching headers on html requests, which seems good to have regardless.

Transformation is still allowed for asset requests.

Fixes: #19309

[wxiaoguang]

This PR will close #19309

• Use Cache-Control: no-transform to disable Cloudflare auto minify #19309

[silverwind]

AddCacheControlToHeader now accepts a slice of string, so this should be very flexible now.

[wxiaoguang]

Golang's nil can be used as empty slice directly, so no need to allocate memory for an empty slice when calling fn(..., []string{}).

Although I think argument additionalDirectives ...string could be more simple:

• fn(..., time) instead of fn(..., time, nil)
• fn(..., time, "no-transform") instead of fn(..., time, []string{"no-transform"})

Current approach is also fine to me.

[silverwind]

Golang's nil can be used as empty slice directly

Thanks, didn't know that. I'm still a golang noob 😉

[zeripath]

I think @wxiaoguang is right and we should use the varargs notation for this so I've pushed up a change to do that.

I guess one thing I'm wondering is if it's really correct that we don't want any caching of our generated html. I guess that's right but it seems bad.

[silverwind]

There's not much point in allowing HTML cache that I see. Content is too dynamic to allow caching. Most pages change on every page load.

$ curl -s 'https://try.gitea.io/silverwind/symlink-test' | md5sum
c5adddf3c81b370ab1312edad42ad4dd  -
$ curl -s 'https://try.gitea.io/silverwind/symlink-test' | md5sum
2a2b1ac6f9bce1196d752b3891ce6ce5  -
$ curl -s 'https://try.gitea.io/silverwind/symlink-test' | md5sum
d0bff48164495658ab1c89c8eb60eb47  -

[wxiaoguang]

IMO one more thing that why Gitea need 'no-store' or 'no-cache': there are a lot of JS code. If the page is cached, then when users make the browser navigate back to a history page, if the page is cached, then the JS won't be executed, the UI may be stuck in a strange state. So Gitea should tell browsers to reload every page during navigation.

[silverwind]

We are in good company regarding anti-cache headers on HTML:

gitlab: max-age=0, private, must-revalidate
github: no-store

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

https://try.gitea.io/silverwind/symlink-test

sorry, late to the party: I checked and I think the only thing changing here (for consecutive requests) is the embedded csrf token, in fact most of the page stays the same (until something changes of course, a month from now the dates will show +1 in "X months ago") for quite some time.

do we know how these changes affect deployments with Gitea behind proxies?

won't adding no-transform tell proxies to stop compressing Gitea pages?

should no-cache really be added as a new hard-coded global default because some people didn't visit their CloudFlare settings page?
wouldn't it be better to have this tweakable from the config?

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

We are in good company regarding anti-cache headers on HTML:

gitlab: max-age=0, private, must-revalidate github: no-store

since Gitea is not a hosted service, I'd really prefer if this stayed user-tunable, e.g. in my set-up, Cache-Control headers are set on the proxy sitting in front of Gitea. granted, there are instances when it absolutely makes sense for the application to set these headers.

[silverwind]

won't adding no-transform tell proxies to stop compressing Gitea pages?

Yes, it's a hint to not transform responses. Cloudfare does destructive HTML minification per default and that problem came up a few times in the past. I don't think no-transform should generally prevent compression via content-encoding as that it's non-destructive.

There's no real spec for what the header allows/forbids, but I think it's mostly the destructive stuff. If you control the proxy, you can of course always do whatever you like, this header is just a hint to automated systems.

[wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf]

won't adding no-transform tell proxies to stop compressing Gitea pages?

Yes, it's a hint to not transform responses. Cloudfare does destructive HTML minification per default and that problem came up a few times in the past. I don't think no-transform should generally prevent compression via content-encoding as that it's non-destructive.

There's no real spec for what the header allows/forbids, but I think it's mostly the destructive stuff. If you control the proxy, you can of course always do whatever you like, this header is just a hint to automated systems.

thanks for the reply.

that probably means with nginx I'll have to start clearing headers before setting them...will test, report back in case of trouble.