Skip to content

Conversation

aytchell
Copy link

@aytchell aytchell commented Oct 5, 2025

If a server sends "Cache-Control: max-age=0" this might be a misconfiguration on the server; in this case we should ignore it (the behaviour up to now).
It might also mean, that the content potentially already expired; for this case this commit provides a new configuration parameter to respect this response.

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

New configuration parameter so that Cache-Control: max-age=0 can be treated the same as Cache-Control: no-cache

⤵️ What is the current behavior?

Currently, if the server responds with Cache-Control: max-age=0, the library ignores this and sets the max-age to one week.

🆕 What is the new behavior (if this is a feature change)?

See above. The default beahaviour is left as-is.

💥 Does this PR introduce a breaking change?

No

🐛 Recommendations for testing

📝 Links to relevant issues/docs

I've seen the discussion in #283

In my app I have this issue: I'm contacting an API (which I cannot control or change) and this API delivers "some kind of" real time data (results for sport games). The server delivers json files; the response contains an etag header and the header Cache-Control: max-age=0. So I periodically poll this endpoint and if the etag is still valid I go with the cached file.

But the current behaviour of the lib gives me the cached file regardless if the json changed or not. By setting the Config parameter which is introduced here, I can properly work with the API.

I added a new FAQ to the README.md.

🤔 Checklist before submitting

  • All projects build
  • Follows style guide lines (code style guide)
    • I mostly followed the style guide; but (I'm new to flutter) I got an error when running flutter format . and dart format . reformatted the whole project. So ... I hope the code formatting is fine.
  • Relevant documentation was updated
  • Rebased onto current develop

If a server sends "Cache-Control: max-age=0" this might be a
misconfiguration on the server; in this case we should ignore it (the
behaviour up to now).
It might also mean, that the content potentially already expired; for
this case this commit provides a new configuration parameter to respect
this response.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant