Also confusing matters is the fact that, while the RSS spec specifies RFC822 (2-digit year) for the date format, the example given in the spec is based on RFC 2822 (4-digit year). It might not be that critical of a problem now, but it will be in around 33 years.
At this point, who knows which will happen first: Email Confirmer gaining security policy coverage, or Drupal core gaining email change confirmation?
🐛 Use email verification when changing user email addresses Needs work
The patch in #8 fixes it for me.
I implemented something like this today as a custom code plugin for Metatag 2.0.x, which can support multiple RSS links, but without the (apparently optional, but possibly desirable) title attributes. I'm not entirely sure how to include fields for both attributes, much less have multiple values for both, if that's even practical or possible with the module's UI. I could roll what I have into a patch for 2.0.x, if there's interest, but would need to know what group and weight value I should assign it.
No podcast here, but I wanted to properly associate an RSS feed for the site without the icon at the bottom of the front page view. I also wanted to add the tag to article pages, for Google Discover purposes.
If I make the bucket public, and turn off S3 authentication on the CDN side, it works with the VersionId and no signing. Thankfully, it seems like the free egress agreement between the CDN and BackBlaze is still in effect with that configuration, so I'm not double-billed for bandwidth in the case of a cache miss.
In any case, I'm actively not using versioning with BackBlaze for this, even though I can't turn it off completely. The bucket is configured to only keep the latest version of any particular object.
The current time-based view caching implementation is useful, as long as it's understood what it does, which is setting the max age for query results and rendered output. Unfortunately, the labeling for those config options doesn't make that clear. Cached items might still be invalidated because underlying content has changed, but if you're not setting a minimum age then there's no harm done.
As for use cases for the way it currently works, I can think of two right away:
1) The "time ago" date/time field formatter that's built into the core. With only tag-based caching, you might see an update or creation time of "2 hours ago", which could actually be days ago if nothing has changed in that time.
2) A notification page that I recently built, with dynamic highlighting of messages posted in the last 24 hours. The highlighting is done in the Twig template so, if the rendered output is only refreshed when new notifications are posted, it could be stuck for days.
In both cases, tag-based invalidation is also desired, so that the views reflect changes to underlying content.
That's not to say that a min-age setting wouldn't be useful in some cases, but it should be in addition to (not instead of) a max-age setting.