Overview
GitHub API (v3) does not correctly interpret the "If-Modified-Since" request header for items that have been created since the time provided.
GitHub API (v3) returns a 304 (Not modified) status even when the data has in fact changed since the time provided by the "If-Modified-Since" request header.
I have determined this is not a race condition caused by sub-second inaccuracies - it can be reproduced even the the item was created many seconds after the "If-Modified-Since" time. (I have not tested it find the actually limit where the bug does not reproduce, but it is over 60 seconds which might as well be forever.)
This is a major issue causing problems for Jenkins users, but will effect any client that does cache checking using "If-Modified-Since".
Environment
Any client that uses caching which attempts to use "If-Modified-Since" to check the validity of previously queried data.
In this example, "If-Modified-Since" is used by OkHttp to check the validity of previously queried URL that returned 404.
Repro steps
This PR shows a unit test the reproduces this issue: #665.
- Create a client that uses caching (OkHttp with
- Request git ref "refs/heads/new_branch" . Returns 404 file not found response. This response is added to the cache.
- (Optional) Wait 10 seconds.
- Create git ref "refs/heads/new_branch" (manually or using API).
- Request git ref "refs/heads/new_branch". Cache automatically adds "If-Modified-Since" time from the response in step 2.
Expected result
200 Response with body data matching the newly created ref "refs/heads/new_branch"
Actual result
304 Response with ETAG matching the newly created ref "refs/heads/new_branch".
Outcome
Client behaves correctly given 304 and treats the previous 404 as still valid.
Later requests from this client with automatically include the ETAG and continue to get 304 that gets treated as 404.
Ref exists but cannot be seen by this client until local cache ages out or the git ref "refs/heads/new_branch" is updated.
Overview
GitHub API (v3) does not correctly interpret the "If-Modified-Since" request header for items that have been created since the time provided.
GitHub API (v3) returns a 304 (Not modified) status even when the data has in fact changed since the time provided by the "If-Modified-Since" request header.
I have determined this is not a race condition caused by sub-second inaccuracies - it can be reproduced even the the item was created many seconds after the "If-Modified-Since" time. (I have not tested it find the actually limit where the bug does not reproduce, but it is over 60 seconds which might as well be forever.)
This is a major issue causing problems for Jenkins users, but will effect any client that does cache checking using "If-Modified-Since".
Environment
Any client that uses caching which attempts to use "If-Modified-Since" to check the validity of previously queried data.
In this example, "If-Modified-Since" is used by OkHttp to check the validity of previously queried URL that returned 404.
Repro steps
This PR shows a unit test the reproduces this issue: #665.
Expected result
200 Response with body data matching the newly created ref "refs/heads/new_branch"
Actual result
304 Response with ETAG matching the newly created ref "refs/heads/new_branch".
Outcome
Client behaves correctly given 304 and treats the previous 404 as still valid.
Later requests from this client with automatically include the ETAG and continue to get 304 that gets treated as 404.
Ref exists but cannot be seen by this client until local cache ages out or the git ref "refs/heads/new_branch" is updated.