4 ms·

This 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 h

by Laaas 4y ago

This 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.

mihaaly 4y ago
I thought the content is more important than getting whatever quickly... Rename the file to get what you want, am I the only one finding that a very strange approach?
croes 4y ago
So we are back to file_v1, file_v1.1, file_v1.2 etc?
- nix23 4y ago
  Like OpenVMS makes it on Filesystem level where the highest version is the "real" one: Blupblub;1 Blupblub;2 --> Blupblub;2 = Blupblub Actually a good idea ;)
- jack_pp 4y ago
  Nah, file_v1_final_final_REALLY_final
- 9dev 4y ago
  No, we are where we should have always been: > GET /file/latest HTTP/1.1 < HTTP/1.1 302 Found < Location /path/to/real/file/hash.tar.gz
  - akerl_ 4y ago
    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.
    - wielebny 4y ago
      Per RFC 2616: > This response is only cacheable if indicated by a Cache-Control or Expires header field.
subtra3t 4y ago
So we need to use file_dec_2, file_nov_2, the sort of hacks version control systems were meant to replace?
- IanCal 4y ago
  You can use git or use the commit sha, you only need to name the files if you refuse to use the provided versioning and tooling and want GitHub to act as a file host.
IanCal 4y ago
The commit ID seems to be part of the URL you can use https://raw.githubusercontent.com/burekasKodi/repository.burekasKodi/0440dafb4450b235bc3ea25767804d2372889257/addons.xml https://raw.githubusercontent.com/burekasKodi/repository.bur... I'm fine with them caching "latest" tbh.
- Aeolun 4y ago
  I’m not fine with latest not actually being latest. That defeats the point of the URL.
  - IanCal 4y ago
    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.
    - Aeolun 4y ago
      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.
  - 8note 4y ago
    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
    - xboxnolifes 4y ago
      Guess we may as well throw our handa up in the air then and set a 14 year cache ttl.
iLoveOncall 4y ago
> 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_time_its_really_final. Your suggestion to work around this GitHub bug is to essentially not use Git. Ridiculous.
- IanCal 4y ago
  No, using git works just fine, as does specifically referencing the version want.
- EdwardDiego 4y ago
  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.
  - ahepp 4y ago
    Well, I think it’s probably fair for users to expect a site advertising itself as a great web host for git to not serve stale files over web protocols. It’s kinda the entire point of the website. Maybe it’s a bit questionable to use the raw feature as a content host, but GitHub has intentionally moved pretty fair from plain old git (I believe people call this a “moat”) I’m sure there are plenty of other players competing for users that would be happy to solve the problem for free.
  - iLoveOncall 4y ago
    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.
    - 4y ago
ahepp 4y ago
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.

by Laaas 4y ago

mihaaly 4y ago

I thought the content is more important than getting whatever quickly... Rename the file to get what you want, am I the only one finding that a very strange approach?

croes 4y ago

So we are back to file_v1, file_v1.1, file_v1.2 etc?

nix23 4y ago
Like OpenVMS makes it on Filesystem level where the highest version is the "real" one: Blupblub;1 Blupblub;2 --> Blupblub;2 = Blupblub Actually a good idea ;)
jack_pp 4y ago
Nah, file_v1_final_final_REALLY_final
9dev 4y ago
No, we are where we should have always been: > GET /file/latest HTTP/1.1 < HTTP/1.1 302 Found < Location /path/to/real/file/hash.tar.gz
- akerl_ 4y ago
  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.
  - wielebny 4y ago
    Per RFC 2616: > This response is only cacheable if indicated by a Cache-Control or Expires header field.

subtra3t 4y ago

So we need to use file_dec_2, file_nov_2, the sort of hacks version control systems were meant to replace?

IanCal 4y ago
You can use git or use the commit sha, you only need to name the files if you refuse to use the provided versioning and tooling and want GitHub to act as a file host.

IanCal 4y ago

The commit ID seems to be part of the URL you can use https://raw.githubusercontent.com/burekasKodi/repository.burekasKodi/0440dafb4450b235bc3ea25767804d2372889257/addons.xml https://raw.githubusercontent.com/burekasKodi/repository.bur... I'm fine with them caching "latest" tbh.

Aeolun 4y ago
I’m not fine with latest not actually being latest. That defeats the point of the URL.
- IanCal 4y ago
  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.
  - Aeolun 4y ago
    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.
- 8note 4y ago
  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
  - xboxnolifes 4y ago
    Guess we may as well throw our handa up in the air then and set a 14 year cache ttl.

iLoveOncall 4y ago

> 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_time_its_really_final. Your suggestion to work around this GitHub bug is to essentially not use Git. Ridiculous.

IanCal 4y ago
No, using git works just fine, as does specifically referencing the version want.
EdwardDiego 4y ago
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.
- ahepp 4y ago
  Well, I think it’s probably fair for users to expect a site advertising itself as a great web host for git to not serve stale files over web protocols. It’s kinda the entire point of the website. Maybe it’s a bit questionable to use the raw feature as a content host, but GitHub has intentionally moved pretty fair from plain old git (I believe people call this a “moat”) I’m sure there are plenty of other players competing for users that would be happy to solve the problem for free.
- iLoveOncall 4y ago
  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.
  - 4y ago

ahepp 4y ago

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.