What about having their own servers instead of misusing Github?
GitHub is aggressively caching raw.github, breaking many use cases
51–60 of 145 posts
Re: GitHub is aggressively caching raw.github, breaking many use cases
#52This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
No, using git works just fine, as does specifically referencing the version want.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#53If only GitHub's underlying technology Git had a way to trigger actions when a file is updated and they could use that to invalidate cache! One day maybe?
Re: GitHub is aggressively caching raw.github, breaking many use cases
#54This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
> if you want to be sure of you get the latest version, rename the file. This is a beyond ridiculous statement. It is a BUG that you do not get the latest version of the file when viewing raw, not an error you made that you should address by having a filename driven versioning system. If I'm using Git and GitHub, it's specifically to NOT have to deal with v1, v1.1, final, final_for_real, final_of_the_finalest, this_t…
Ridiculous is expecting a service you're not paying for to serve files in a way that fits your use case when you've never entered into a contract that guarantees the behaviour you're relying on.
You can use Git just fine without GitHub.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#55Earlier quoted context omitted.
Yes, naming things is intimately tied to cache invalidation. That's why the two things are together in that maxim. Not sure why people think it has to so with naming variables or functions...
> That's why the two things are together in that maxim. I think you missed the joke.
Did they?
Re: GitHub is aggressively caching raw.github, breaking many use cases
#56Earlier quoted context omitted.
If the TTL starts at 86400 and then declines to 0 before resetting.. this is a fairly common caching strategy... it ensures the cache will expire for all clients at around the same time. For example, if you want the client's cache to expire at midnight everyday.
That's a terrible idea. Source: Implemented global TTL in our own caching DNS in front of kube-dns (which is horrible if you, among other things, have node containers with no DNS caching; i still have a pcap with 20000+ queries for A in s3.amazonaws.com in a 0.2s span) before coredns was a thing. The CPU spikes were huge, but remained hidden for a long time due to metrics resolution. But eventually it got bad enough…
There are circumstances where that’s the right strategy. For example, GitHub may be using it to ensure two requests for two different files in a repo receive the same version of the repo.
Not saying they’re doing that.. just explaining the cache strategy.
An explanation isn’t a recommendation for you to go out and apply it to everything.
Source: founded and operated a cdn for 5 years of my life.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#57This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
So we are back to file_v1, file_v1.1, file_v1.2 etc?
No, we are where we should have always been:
> GET /file/latest HTTP/1.1
Re: GitHub is aggressively caching raw.github, breaking many use cases
#58I'm guessing that a lot of people embed these files in their website in one way or another, making aggressive caching necessary.
I discovered the issue when I reported an adblock filter list that broke a site.
The issue was fixed within minutes, but the broken filter list is still being served.
Thankfully, it turned out to be a bug.
Re: GitHub is aggressively caching raw.github, breaking many use cases
#59Re: GitHub is aggressively caching raw.github, breaking many use cases
#60This seems reasonable to me. Caches should last longer; if you want to be sure of you get the latest version, rename the file. a good trick is to include the hash of the file in the name to get content-addressing à la IPFS.
Seeing as it’s git, can’t you just do content based hashing through the commit hash?
And I’d assume the GitHub api has a way to get the hash for the head of a branch?
I don’t know, I guess the entire point of GitHub is to be able to obtain up-to-date files, so maybe they should just improve the caching.