You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cache will use whatever method is supported depending on the presence of various header fields:
ETag
Last-Modified
However, I encountered a corner-case when using conditional requests with GitHub, where using ETags leads to unwanted behavior, see eclipse-csi/otterdog#201 for a summary of the problem.
It would be useful if in such cases you can control what type of information is used when sending such a conditional request, e.g. limit to the use of the Last-Modified field.
Use case
Being able to use stable conditional requests with the GitHub Rest API when using installation tokens that have to be rolled every hour.
Workarounds
There is no known workaround atm afaict, the cache will invalidate itself when a new token is being used.
Plan to implement
Tbh I am not sure if this really a useful feature or just adds complexity, it eventually should be fixed on GitHub side, but I wanted to raise and discuss this issue here as well.
The text was updated successfully, but these errors were encountered:
Interesting, I definitely wasn't aware of that behavior.
The GitHub API is a common enough use case that I'd be willing to add a workaround for that in this library. But since it may no longer be relevant if/when GitHub fixes this on their end, maybe this could be exposed as an undocumented/internal flag instead of part of the public API?
I am not sure if disabling etag altogether results in a net-positive effect in the case of GitHub and changing tokens. The downside is that only Last-Modified headers are used, and these are not present for all API calls. This means that various calls do not benefit from conditional requests anymore.
A logic that would prefer Last-Modified over ETag when present would be more desirable imho. Right now the logic just uses any cache header that is present to construct the conditional request, however, if an Etag is present, and the token changed GitHub will return a fresh response. So in the special case of GitHub (until it might be fixed), if a Last-Modified header is present, use that to construct a conditional request, otherwise, use the ETag as a best effort.
That could work imho, would need to test how well GitHub handles If-Modified-Since headers.
Feature description
The cache will use whatever method is supported depending on the presence of various header fields:
However, I encountered a corner-case when using conditional requests with GitHub, where using ETags leads to unwanted behavior, see eclipse-csi/otterdog#201 for a summary of the problem.
It would be useful if in such cases you can control what type of information is used when sending such a conditional request, e.g. limit to the use of the Last-Modified field.
Use case
Being able to use stable conditional requests with the GitHub Rest API when using installation tokens that have to be rolled every hour.
Workarounds
There is no known workaround atm afaict, the cache will invalidate itself when a new token is being used.
Plan to implement
Tbh I am not sure if this really a useful feature or just adds complexity, it eventually should be fixed on GitHub side, but I wanted to raise and discuss this issue here as well.
The text was updated successfully, but these errors were encountered: