solid
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.
Yup, this has been a favorite topic of mine for a very long time, it is really important to get caching right in decentralized systems, and that's not only certain MIME types, but data that is used a lot.
Currently, the spec only references RFC7234 (which is the caching part of HTTP) as a normative reference, but as that doesn't say much in terms of hard requirements, not a lot has been implemented.
As you correctly point, using Cache-Control: max-age, which is the most powerful mechanism since it tells the client it doesn't need to do a request at all, requires that someone understands that they have content that will not change into the future, and is able to make that commitment. That would often be a human judgement, and that human is likely to sit on the client side.
In terms of mechanics, I can imagine many ways to do this, for example an auxiliary resource that you put a triple with dct:valid into, and that would be used by the server for max-age, but I feel that there has to be a lot of UX work for people to make these commitments, so I have been hesitant to introduce that suggestion before we've done a more thorough exploration of the UX on the client side.
I think this question also belongs into the topic of metadata editing.
Here is another use case for why setting Cache-Control or time to live headers is important.
A Linked Data Event Streams (LDES)) (ldes:EventStream) is a collection (rdfs:subClassOf tree:Collection) of immutable objects, each object being described using a set of RDF triples
In order for that to work, it must be possible for a client creating such a resource to set the time to live. Some resources will be changing for a day, and then be immutable...
cc @woutslabbinck, @philippecarlo, @ajuvercr
