Consider emphasizing storability

[CosmicHorrorDev]

CachePolicy::is_storable() is pretty easy to overlook for upholding a MUST NOT guarantee. Maybe it would be a better idea to force it into an explicit action by making constructing a CachePolicy fallible that way consumers who are only interested in storable policies can just ignore the Err case. Something like

pub struct NotStorable(pub CachePolicy);

impl CachePolicy {
    pub fn new(...) -> Result<Self, NotStorable> { ... }
    pub fn new_options(...) -> Result<Self, NotStorable> { ... }

[kornelski]

is_storable is easy to miss indeed. However, no-store is supposed to apply to "non-volatile" storage only. I'm concerned that failing in the constructor will break in-memory-only caches and deny access to other features.

[CosmicHorrorDev]

I have some docs covering what I suspect the different use-cases would be here for handling the return types

https://github.com/CosmicHorrorDev/rusty-http-cache-semantics/blob/53885e29e63abdf1d170e3d00524c5be11a50023/src/lib.rs#L186-L220

Failing in the constructor is very easy to recover from for people that want CachePolicies regardless of whether or not they should be stored, as it's just let policy = CachePolicies::new(...).unwrap_or_else(|not_storable| not_storable.0) (and I intentionally didn't implement any of the common Error related traits for NotStorable as well to dissuade trying to return it as an error). All of that said I don't think there's any risk with breaking in-memory-only caches nor denying access to other features

Really the Result is only being used as a stand-in for some Either type. An alternative could be returning some

enum MaybeStore {
    NotStorable(CachePolicy),
    Storable(CachePolicy),
}

instead. I'm unsure if that's really an improvement or not 🤷

---

Another other alternative could be having a serialization error return when trying to serialize a CachePolicy that's not storable, but that seems way way more problematic which is why I didn't opt for it

[CosmicHorrorDev]

I'm also unsure if you should really keep no-store policies in in-memory caches either. From the spec (emphasis mine)

https://httpwg.org/specs/rfc9111.html#cache-request-directive.no-store

5.2.1.5. no-store

The no-store request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

...

(and the same bit is repeated for the no-store response directive)