4 ms·

This will be interesting... I just did a grep of my local codebases and found 11 instances where CSS or JS resources were being downloaded from rawgit.com. I h

This will be interesting... I just did a grep of my local codebases and found 11 instances where CSS or JS resources were being downloaded from rawgit.com. I have a feeling when it's turned off, a lot of sites are going to break.

jimaek 8y ago
Ryan is not going to allow any sites to break. Still, everyone should switch to an alternative
- Gaelan 8y ago
  Until “at least October of 2019”. Who knows what’ll happen after that
  - rgrove 8y ago
    I know! :D
    - Gaelan 8y ago
      …and? :)
      - onion2k 8y ago
        And, ultimately, it's not rawgit's job to maintain a website. If you use a free service as part of your deployment it's your job to keep an eye on it in case it shuts down. Rawgit has provided a fantastic service that's proved very useful and I'm glad it's been available as long as it has.
        manquer 8y ago
        It is bit more complex than that. it is incredibly hard to keep an eye on whether a library you use has a dependency which uses such services, and even if they fix it in the next version it may not be fixed in the version you use.
        onion2k 8y ago
        If you're deploying your website and you don't know where assets are coming from then something has gone very, very wrong. You can't just ignore security completely and thrn blame a CDN provider if things break.
rgrove 8y ago
Yeah, I really, really don't want to break things, so I've tried to be very careful about how I'm doing this. In the shutdown announcement I committed to keeping the site running in sunset mode for at least a year. Hopefully that's plenty of time for everyone who's aware of the shutdown to migrate, but I expect there will be stragglers. My unofficial, subject-to-change plan for dealing with that is that at the end of the sunset year, if there's still a significant amount of traffic, I'll start throttling requests to make RawGit slower. Hopefully people will notice their websites are slow and will investigate. I'll also try to notify stragglers individually by filing issues against their GitHub repos if possible.
- mhils 8y ago
  Instead of throttling, you could also consider doing incremental brownouts where you drop requests for the first ten minutes every hour. PyPI did this recently when they phased out TLS 1.0, which worked really well IMO.
  - rgrove 8y ago
    Thanks for the suggestion! This does seem potentially more effective.
    - Klathmon 8y ago
      IIRC Google also uses (or used) a similar system for deprecating old APIs. Start with failing 1% of requests randomly and slowly ramp up from there.
  - wild_preference 8y ago
    I wish more services shuttered this way because you can’t miss it. I once had a web host generously give me three months to pay a delinquent bill that I missed the emails for. Sadly it just meant I thought things were fine. When they finally shut my service down, my users made me aware within minutes but it was too late.
  - martey 8y ago
danShumway 8y ago
This is one of the biggest reasons I want the web to start moving towards content-addresses instead of location-addresses. It's unreasonable to expect that a service like rawgit would stay online forever. But even if someone else steps in and builds something equivalent, or if sites turn around and start self-hosting, all of those URLs still need to change. People focus on the flashy parts of DAT and IPFS like, "oh, someone else could host my website." But there's a much more mundane and arguably much more important side of that which is, "One day NPM might have a different URL." Rehosting content is pretty easy, getting sites and dependencies to link to it is very hard. And it's not just the problem of updating all of your own projects, there are projects that aren't going to be updated. Rgrove is being super nice about all of this, but there are sites that are going to break in a year, and nobody can really do much of anything about it.

jimaek 8y ago

Ryan is not going to allow any sites to break. Still, everyone should switch to an alternative

Gaelan 8y ago
Until “at least October of 2019”. Who knows what’ll happen after that
- rgrove 8y ago
  I know! :D
  - Gaelan 8y ago
    …and? :)
    - onion2k 8y ago
      And, ultimately, it's not rawgit's job to maintain a website. If you use a free service as part of your deployment it's your job to keep an eye on it in case it shuts down. Rawgit has provided a fantastic service that's proved very useful and I'm glad it's been available as long as it has.
      - manquer 8y ago
        It is bit more complex than that. it is incredibly hard to keep an eye on whether a library you use has a dependency which uses such services, and even if they fix it in the next version it may not be fixed in the version you use.
        onion2k 8y ago
        If you're deploying your website and you don't know where assets are coming from then something has gone very, very wrong. You can't just ignore security completely and thrn blame a CDN provider if things break.

rgrove 8y ago

Yeah, I really, really don't want to break things, so I've tried to be very careful about how I'm doing this. In the shutdown announcement I committed to keeping the site running in sunset mode for at least a year. Hopefully that's plenty of time for everyone who's aware of the shutdown to migrate, but I expect there will be stragglers. My unofficial, subject-to-change plan for dealing with that is that at the end of the sunset year, if there's still a significant amount of traffic, I'll start throttling requests to make RawGit slower. Hopefully people will notice their websites are slow and will investigate. I'll also try to notify stragglers individually by filing issues against their GitHub repos if possible.

mhils 8y ago
Instead of throttling, you could also consider doing incremental brownouts where you drop requests for the first ten minutes every hour. PyPI did this recently when they phased out TLS 1.0, which worked really well IMO.
- rgrove 8y ago
  Thanks for the suggestion! This does seem potentially more effective.
  - Klathmon 8y ago
    IIRC Google also uses (or used) a similar system for deprecating old APIs. Start with failing 1% of requests randomly and slowly ramp up from there.
- wild_preference 8y ago
  I wish more services shuttered this way because you can’t miss it. I once had a web host generously give me three months to pay a delinquent bill that I missed the emails for. Sadly it just meant I thought things were fine. When they finally shut my service down, my users made me aware within minutes but it was too late.
- martey 8y ago

danShumway 8y ago

This is one of the biggest reasons I want the web to start moving towards content-addresses instead of location-addresses. It's unreasonable to expect that a service like rawgit would stay online forever. But even if someone else steps in and builds something equivalent, or if sites turn around and start self-hosting, all of those URLs still need to change. People focus on the flashy parts of DAT and IPFS like, "oh, someone else could host my website." But there's a much more mundane and arguably much more important side of that which is, "One day NPM might have a different URL." Rehosting content is pretty easy, getting sites and dependencies to link to it is very hard. And it's not just the problem of updating all of your own projects, there are projects that aren't going to be updated. Rgrove is being super nice about all of this, but there are sites that are going to break in a year, and nobody can really do much of anything about it.