New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build status image's being cached in Chrome #822

Closed
tbranyen opened this Issue Dec 27, 2012 · 10 comments

Comments

Projects
None yet
8 participants
@tbranyen
Copy link

tbranyen commented Dec 27, 2012

I kept seeing Build status failing in my project in a separate branch and created this issue to track:

https://github.com/tbranyen/backbone.layoutmanager/issues/241

I then Tweeted @travis-ci and realized it was a cache issue. Upon clearing my cache, the build status correctly showed up as Success.

I'm unsure if this is headers related or yet-another-aggressive-google-cache. Would be great to hear if others are having the same issue.

Let me know if you need more information.

@izuzak

This comment has been minimized.

Copy link

izuzak commented Dec 27, 2012

Since I'm observing the same issue, here is some debugging info.

I have two Chrome windows open, one is my "regular" Chrome in which I didn't clear the cache, and the other one is my "incognito" window with a clear cache. I have recently broken the travis build for a project, and it's travis image is here: https://api.travis-ci.org/izuzak/noam.png (shows failing). While my window with a cleared cache shows the correct image (failing), the window which has previously cached the image (success) still shows success. (When I say "browser with a cleared cache", I just mean that I cleared the cache after the latest travis build -- this browser didn't see the previous build status image from travis).

Here are the HTTP requests and responses for both windows:

Request from browser with a non-empty cache (shows wrong image):

GET /izuzak/noam.png HTTP/1.1
Host: api.travis-ci.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.24 (KHTML, like Gecko) Chrome/26.0.1370.0 Safari/537.24
Referer: https://github.com/izuzak/noam#development
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hr;q=0.6
Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3
Cookie: <DELETED>
If-None-Match: "6ce124569c279b356f2968b8e2d8ab69"
If-Modified-Since: Sun, 23 Dec 2012 14:43:25 GMT

Response from browser with a non-empty cache (shows wrong image):

HTTP/1.1 304 Not Modified
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Cache-Control, Expires, Etag, Last-Modified
Cache-Control: no-cache
Content-Disposition: inline; filename="failing.png"
Date: Thu, 27 Dec 2012 13:40:40 GMT
Etag: "a1507812d18eba31b29ab1354cc647c2"
Expires: Thu, 27 Dec 2012 13:40:39 GMT
Status: 304 Not Modified
Strict-Transport-Security: max-age=31536000
Vary: Accept
X-Accepted-OAuth-Scopes: public
X-Oauth-Scopes: public
Connection: keep-alive

Request from browser with an empty cache (shows correct image):

GET /izuzak/noam.png HTTP/1.1
Host: api.travis-ci.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.24 (KHTML, like Gecko) Chrome/26.0.1370.0 Safari/537.24
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hr;q=0.6
Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3
If-None-Match: "a1507812d18eba31b29ab1354cc647c2"
If-Modified-Since: Sun, 23 Dec 2012 14:43:25 GMT

Response from browser with an empty cache (shows correct image):

HTTP/1.1 304 Not Modified
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Cache-Control, Expires, Etag, Last-Modified
Cache-Control: no-cache
Date: Thu, 27 Dec 2012 13:37:00 GMT
Etag: "a1507812d18eba31b29ab1354cc647c2"
Status: 304 Not Modified
Strict-Transport-Security: max-age=31536000
Vary: Accept
X-Accepted-OAuth-Scopes: public
X-Oauth-Scopes: public
Connection: keep-alive

Notice that the response in both cases is a 304 Not modified with an ETag "a1507812d18eba31b29ab1354cc647c2", although the first request has a different If-None-Match header value ("6ce124569c279b356f2968b8e2d8ab69") than the response ETag value. This is the cause of the problem -- the response must not be a 304 if these request and response hashes are not the same. The response to the second request is OK since the value of the request hash is the same as in the response ETag (the browser with a clear cache didn't see the previous image, only the current one... so it sends the latest hash in the request).

@cjerdonek

This comment has been minimized.

Copy link

cjerdonek commented Jan 12, 2013

I experienced this same issue, and I'm using Chrome. It's annoying because even if you open the image URL in a separate tab and refresh, it still shows the wrong (failing) status. Altering the URL (e.g. by appending a ?) shows the correct status, which also suggests that it is related to caching.

@joshk

This comment has been minimized.

Copy link
Member

joshk commented Jan 12, 2013

@rkh, can you please have a look into this :)

On 13/01/2013, at 9:54 AM, Chris Jerdonek notifications@github.com wrote:

I experienced this same issue, and I'm using Chrome. It's annoying because even if you open the image URL in a separate tab and refresh, it still shows the wrong (failing) status. Altering the URL (e.g. by appending a ?) shows the correct status, which also suggests that it is related to caching.


Reply to this email directly or view it on GitHub.

@rkh

This comment has been minimized.

Copy link
Member

rkh commented Jan 13, 2013

Yes, will do.

@dalehenrich

This comment has been minimized.

Copy link

dalehenrich commented Mar 11, 2013

It appears that this issue is still occurring ... kinda limits the whole utility of displaying the status images if they don't reflect the actual status of the project .... considering removing the links from the project pages:(

@geek

This comment has been minimized.

Copy link

geek commented Mar 11, 2013

It looks like the Last-Modified header isn't updated when a status image is supposed to change.

@drogus

This comment has been minimized.

Copy link
Member

drogus commented Mar 11, 2013

@wpreul thanks for help! now it's obvious what's going on, we missed it before, I'm pushing a fix.

@drogus

This comment has been minimized.

Copy link
Member

drogus commented Mar 11, 2013

Last-Modified header should be correctly set now, please let me know if it fixed things for you.

@geek

This comment has been minimized.

Copy link

geek commented Mar 11, 2013

That appears to have done the trick. Thank you for the quick turnaround.

@drogus

This comment has been minimized.

Copy link
Member

drogus commented Mar 11, 2013

Sweet! I'm closing this, please comment or reopen if you have any more problems with cached images.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment