Allow clients to configure caching headers

In the current spec, there is no mention of which caching headers should be returned for resources, so I suppose the current approach is to leave that decision to POD implementers. However, there are some situations where it would be desirable to configure them depending on the nature of the files, not only their mime-types.

For example, I'm building an application to manage cooking recipes, and I will allow users to upload their own images. I have noticed that the current implementations (at least the ones I've tried) don't return the Cache-Control header at all, so clients would be requesting the image every time (even though some of them return ETag, which would improve the performance, but it's still not ideal). Given the nature of these images, I would like to cache them for a long time. Furthermore, if the image in cache becomes stale, I wouldn't mind using those when the application is offline.

Given that use-case, images seem like a good candidate to have long-lived caching headers by default. But there may be some edge cases where this is not desirable, for example images that change more frequently and shouldn't be used when stale.

Keeping all that in mind, I think it would be nice if PODs have some defaults for each mime-type (at the discretion of each POD implementation), but it's possible to configure by clients that create or manage these files. I could see this working in a similar way to ACLs for example.

The issue names no repository file, test, or entry point to change. Start by reviewing the existing resource and ACL configuration sections in the specification, then determine how cache defaults and client overrides should be represented and what behavior should be normative. Done means the specification clearly defines caching-header configuration, defaults, and stale-resource behavior.