81–90 of 145 posts
Earlier quoted context omitted.
Github did layoffs, yes. We'll see how much longer the site can stay up. This is a death rattle.
GitHub is among many tech companies currently shedding fat from hiring during the pandemic boom. The morality of that is another discussion, but I'd hardly call this a death rattle.
I was surprised to see that sometimes that file was being requested millions of times a day due to attempts to loading it too early. With some optimizations I was able to greatly reduce that by 99%.
Having seen all those requests, I understand why github aggressively caches these files.
I agree that repo owners should be allowed to invalidate those caches upon an API request - or it should happen automatically on every change.
Earlier quoted context omitted.
Github raw seems like the simplest system for solving cache invalidation: invalidate the cache of a changed file when it’s pushed. They have access to both GitHub and the raw service. I know there are usually all sorts of layers between that make interconnectivity logistically complicated, but am I wrong that at the top-level it’s that simple?
That is too simple for the feature they are using. The client itself has its own cache and the only way to fully prevent traffic from a client is to tell it content it caches will remain valid for some amount of time into the future. For URLs that return the latest entry there is no valid amount of time known in advance by GitHub unless they want to introduce mandatory publication delays. For URLs of specific change…
Earlier quoted context omitted.
Github raw seems like the simplest system for solving cache invalidation: invalidate the cache of a changed file when it’s pushed. They have access to both GitHub and the raw service. I know there are usually all sorts of layers between that make interconnectivity logistically complicated, but am I wrong that at the top-level it’s that simple?
That is too simple for the feature they are using. The client itself has its own cache and the only way to fully prevent traffic from a client is to tell it content it caches will remain valid for some amount of time into the future. For URLs that return the latest entry there is no valid amount of time known in advance by GitHub unless they want to introduce mandatory publication delays. For URLs of specific change…
Let’s leave this aside since it both has known client-side mitigations, and is not the cause of the issue that was posted.
I don't think raw was supposed to be used as your CDN
Earlier quoted context omitted.
How do you see that? At leat in my mobile browser nothing jumps into my eye. This user has contributions to @github, but very few. Edit: Found it. Need to click on one of the achievements. Then the layout changes and it appears in the lower left corner under Organizations.
It doesn't appear to be visible on mobile, only desktop.
Earlier quoted context omitted.
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.
So expecting that a raw file isn't outdated is a special usecase now? And I don't see where you see that I'm not a paying user? This issue affects every repository, including ones where the user pays.