Cache header data passthrough #2

New issue

Open

opened 2026-06-01 04:19:11 +00:00 by h · 0 comments

h commented

2026-06-01 04:19:11 +00:00

Owner

It is worth noting that an ideal production deployment would have a caching reverse proxy both between the client and ytrss deployment and between the ytrss deployment and YouTube service, so this feature would improve the effectiveness of caching in that case, as a stale RSS feed served by the local or provider-side YouTube reverse proxy would not have its modified form cached by the ytrss reverse proxy for longer than actually necessary.

Currently, even clients capable of caching RSS feeds are unable to do so. This is an issue, especially since querying the RSS feed endpoint indicates that Google wishes for them to be cached for 15 minutes, and additionally caches them internally. To solve this, it may be worth trying to provide the `Expires` timestamp from the upstream to the client, at least in production deployments. It is worth noting that an ideal production deployment would have a caching reverse proxy both between the client and ytrss deployment and between the ytrss deployment and YouTube service, so this feature would improve the effectiveness of caching in that case, as a stale RSS feed served by the local or provider-side YouTube reverse proxy would not have its modified form cached by the ytrss reverse proxy for longer than actually necessary.

h added the

Kind/Enhancement

Priority

Medium

labels

2026-06-01 04:22:01 +00:00

h referenced this issue

2026-06-01 04:29:55 +00:00

DeArrow integration #3

h added the

Status

Help Wanted