Live data from Hacker News

GitHub is aggressively caching raw.github, breaking many use cases

github.com

131–140 of 145 posts

Re: GitHub is aggressively caching raw.github, breaking many use cases

#131
post #101
post #57

Earlier quoted context omitted.

No, we are where we should have always been: > GET /file/latest HTTP/1.1

Sure... but their CDN is caching the results for /file/latest, so they'd either have to handle cache expiry differently or the same bug would happen.

Per RFC 2616:

> This response is only cacheable if indicated by a Cache-Control or Expires header field.

Re: GitHub is aggressively caching raw.github, breaking many use cases

#133
post #3

There are two hard problems in IT: cache invalidation, naming things and off-by-one errors.

There are actually only two hard problems in computer science: 0) Cache invalidation 1) Naming things 5) Asynchronous callbacks 2) Off-by-one errors 3) Scope creep 6) Bounds checking

Bounds checking as separate from off-by-one just means you stop using C arrays. That's not hard. And why point at callbacks specifically? And scope creep is not a computer science problem; it's easy to avoid if people decide to avoid it.

So this list is too bloated for the joke to work well, I think. Even before we talk about how off-by-one gets ruined this way.

Re: GitHub is aggressively caching raw.github, breaking many use cases

#134
post #130

If 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?

Invalidate browser's cache?

This is not the problem as adding query parameters to bypass that doesn't work.

Re: GitHub is aggressively caching raw.github, breaking many use cases

#135
post #3

There are two hard problems in IT: cache invalidation, naming things and off-by-one errors.

There are actually only two hard problems in computer science: 0) Cache invalidation 1) Naming things 5) Asynchronous callbacks 2) Off-by-one errors 3) Scope creep 6) Bounds checking

7) Yoda logic

Re: GitHub is aggressively caching raw.github, breaking many use cases

#136
post #24
post #13

Earlier quoted context omitted.

That doesn't solve cache invalidation; that just means you're always invalidating the cache even in cases where you don't actually want to.

Content addressing causes the name to change only when the content changes, which also means the name doesn't change if the content doesn't change, this by definition you don't have spurious cache invalidations

There are many problems with that though. For example, if your CSS changes you change the filename... but now you need to change the HTML file that references it. You can't change that easily.

Or what if your CSS change just deletes some unused classes... it'd be fine for users to keep the old version until it expires. If you rename the resource you'll be causing a lot of users to wait unnecessarily. Not a huge problem, unless you're Meta or Google.

And so on.

When people say cache invalidation is hard it's best to believe them, because it is.

Re: GitHub is aggressively caching raw.github, breaking many use cases

#137
post #123
post #63

Earlier quoted context omitted.

I’m not fine with latest not actually being latest. That defeats the point of the URL.

There's a hard limit on that - the speed of light. You can't know what the actual latest is, only some cached value. The actual value may have changed while the message is in flight

Guess we may as well throw our handa up in the air then and set a 14 year cache ttl.

Re: GitHub is aggressively caching raw.github, breaking many use cases

#138
post #88

Earlier quoted context omitted.

It doesn't appear to be visible on mobile, only desktop.

Ah, good catch. We'll try to see if we can fix that in the future so the mobile site shows our staff badges.

But how do we know this post is a GitHub engineer /ponders

Re: GitHub is aggressively caching raw.github, breaking many use cases

#139
post #110
post #63

Earlier quoted context omitted.

I’m not fine with latest not actually being latest. That defeats the point of the URL.

I get the issue but I do strongly feel that you should expect http resources to be cached. It's so common of a thing expecting it to never be cached is unreasonable as a design. I would expect the headers to make this clear, however.

I actually don’t. Git already has a file on the filesystem. Serving a plain file is as close to caching as you are going to get.
Post reply on HN