Transfer the repository to the dedicated organization

[arturdryomov]

Transfer the repository to the dedicated organization

[sockeqwe]

I will check spotify and in worst case reach out to spotify support

[arturdryomov]

All right, we might or might not have a problem with the migration. For some reason GitHub returns 200 on raw.githubusercontent.com on repo migration.

For example, Mainframer was migrated from gojuno to buildfoundation a long time ago. But...

$ curl "https://raw.githubusercontent.com/gojuno/mainframer/3.x/README.md" --verbose                                  

* Trying 151.101.112.133...
* Connected to raw.githubusercontent.com (151.101.112.133) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: www.github.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /gojuno/mainframer/3.x/README.md HTTP/1.1
> Host: raw.githubusercontent.com
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK

At the same time...

$ curl "https://github.com/gojuno/mainframer" --verbose

* Trying 140.82.118.4...
* Connected to github.com (140.82.118.4) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: github.com
* Server certificate: DigiCert SHA2 Extended Validation Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /gojuno/mainframer HTTP/1.1
> Host: github.com
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently

I’m going to contact Pocket Casts about this.

[arturdryomov]

Awaiting Pocket Casts and GitHub replies but I think it is even better than 301.

• 301: since there is no feed on the old URL we are forced to hope that services handle redirects and overrides correctly.
• 200: since the old and the new feed are essentially equivalent is is possible to not change anything and the feed should behave exactly as it behaved before. At the same time I would still add iTunes XML tag and change URL to the new one everywhere so new users follow the actual URL instead of the legacy one. I should note though that users migration by services might or might not work depending on the implementation details.

[arturdryomov]

Damn, it took one month to get replies from both support channels, what a world we live in. I remember times when GitHub responded in minutes, now it is weeks.

GitHub

Is it intended behavior? Are raw URLs going to return 200 for eternity or going to be replaced with 301 on cache invalidation (or any other invalidation)?

Great question! Contents served up on raw.githubusercontent.com are publicly accessible and something we use as a part of our core offering. However, because there isn't documentation for how that server behaves, we don't recommend relying on any exact URLs originating there as it is subject to change at any time.

If you are interested in fetching a specific file hosted in a GitHub.com repository, we recommend using the Contents API, specifically this endpoint:
https://developer.github.com/v3/repos/contents/#get-contents

Because this is a documented resource, we can offer a guarantee that it will work as expected. There are media type options available for end clients to fetch the raw version of the file's contents:
https://developer.github.com/v3/repos/contents/#custom-media-types

Thank you for the information! Unfortunately, we made a mistake and relied on this URL to host the podcast feed :-(
Is there any way we can produce a 301 redirect from the raw URL? I think it is not possible using public-available GitHub methods. If so, we’ll have to use more painful methods, i. e. ask listeners to re-subscribe.

There isn't a way for us on our end or through another interface to produce a 301 redirect from the raw URL.

Pocket Casts

If the old feed will result in 200 but the content will include the itunes:new-feed-url tag — is the feed going to be migrated to the new URL on your servers?

Yes

Do you have any insights about how iTunes might handle this?

Yes, that tag was invented by Apple for just this purpose, so their servers will pick that up.

---

The bad thing — since the feed is accessed via raw GitHub URL we are doomed to lose it eventually, it is just a question of time and someone breaking non-documented compatibility. The only solution here is to move the feed to something more controllable (i. e. a domain) and ask listeners to re-subscribe. Should we do it right away? Probably not. Should we expect this to happen? Yes, I remember how Dropbox nuked their public direct URLs, the same can happen here since it is not GitHub we know, it is Microsoft GitHub with all possible consequences.

The good thing — seems like we can migrate the repo. I’ll work on automating feed generation in this repository ASAP, then we can proceed with the website and then finally we can move the repo.

@artem-zinnatullin, @sockeqwe, WDYT?

[sockeqwe]

Yeah, a own domain seems to be best solution, but it hasn't change in years so I would be fine to keep artemzin/TheContext-Podcast.

We can have a transition phase or support both (rss feed throu domain and artemzin/TheContext-Podcast) as long as possible