Cache 204 - No content

[hpoul]

💬 Questions and Help

If I understand the code correctly currently only 200 and 202 status codes are added to the cache.

https://github.com/Baseflow/flutter_cache_manager/blob/c7881776325441f3900277499615981c40d12284/flutter_cache_manager/lib/src/web/web_helper.dart#L23-L24

In my case I have a image API endpoint which tries to generate a image/logo/etc. based on a user-provided website URL. Since the user input could just as well be an internal URL or just broken, it is perfectly fine for the endpoint to return a 404 response. Right now this is not cached on the client side but requested every time.

Is this the intended behavior, or any way to cache non-existent URLs?

[renefloor]

It is intended behaviour indeed, because there is no image to cache. I can imagine that you might want to cache this sometimes, however this will never be the default. This would need some configuration. For how long would you cache 404's? It doesn't make sense to cache them forever. Maybe a week? (We could also make that configurable.)

[hpoul]

I can imagine that changing the default would be pretty unexpected/breaking.

I think a 404 could be handled the same way as a 200 - ie. parse the Cache-Control header and use that as the cache expiry? If there is no Cache-Control header, I would still use the same default as for a 200. I don't see a reason why a non-existent URL should change more frequently than an existing URL. 🤔️

[renefloor]

Normally you get a 404 because you just have the wrong url and there is nothing meant to be.

parse the Cache-Control header and use that as the cache expiry

I think there are very few sites that would give a Cache-Control header for a 404.

I don't see a reason why a non-existent URL should change more frequently than an existing URL. 🤔️

A non-existing site can 1) change never, because it is non-existing and never meant to exist 2) at some random moment in the future, for things you happened to predict, for example news.com/jesus-came-back. 3) at a certain time in the future, because the url has some structure, for example history.com/2022-04-08.

An existing site has content which is meant to stay there forever or is meant to change regularly, so you can put the Cache-Control header accordingly.

I believe most 404's will never change into a 200, but caching this is risky as there is a chance at any time it does change. A 200 also might change at any time, but in those cases you at least have some old content available instead of nothing.

[hpoul]

I'm thinking whether a 404 is actually the right response for my API in the first place, it seems it is a common practice to return 204 No Content for things like missing /favicon.ico paths.

It seems the spec for 204 indicates that it should be cached, so it might be the better response in the first place 🤔️

A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

Would it make more sense to just add 204 to the cacheable responses? What was the thought about caching 202 accepted? Sounds to me like a strange response to a GET request. 🤔️

[renefloor]

I'm not fully sure anymore about the 202, I think somebody had that request because he created something with the get request. I'll have to search back in the issues.

I think 204 makes sense to cache actually, but currently the cache is not build to support no-data, so that's a bit more work than just adding that status code to the list.

Do you mind if I change the title to Cache 204 - No content?

[hpoul]

Do you mind if I change the title to Cache 204 - No content

@renefloor no, i've just updated it :) thanks

the cache is not build to support no-data, so that's a bit more work

I might give that a try when i've got some time

[rorystephenson]

I'm running in to the same problem, not all images will necessarily exist (in my case the majority won't). @renefloor Is it still the case that this library does not support caching no-data?

I have control over the server so I can change the response code but if I've understood correctly, right now it's not possible to cache a no-data response.