What's the difference between `raw.githubusercontent` and raw in the URL itself-CodePudding

When I see URLs like https://github.com/hasura/graphql-engine/raw/stable/cli/get.sh, it contains "raw" in the URL itself. However when you actually go to that URL, it redirects to "raw.githubusercontent", same as when you went to that file on GitHub and clicked "raw" on the UI.

I assume instinctively it's perhaps because of some legacy thing, perhaps GitHub is redirecting all previous URLs to the new "raw.githubusercontent" URL?

Or is there another reason, is there some difference or something specific that happens when it's specifically "raw" in the URL?

This is made even more confusing when I see there's a difference between new and old URLs on GitHub. The above example is using https://github.com/<org>/<repo>/raw/<branch>/<dir>/<file>. However when you use that on a new repository it looks like https://github.com/<org>/<repo>/blob/<branch>/<dir>/<file> and that then gets converted to raw.githubusercontent. It seems like old repositories didn't use "tree" or "blob" at all in the URLs.

So what exactly is the most up to date and correct way to use it and if I wanted to retrieve the raw content of a file, which URL should I use?

CodePudding user response：

The links you see on github.com are routes that are designed to be used on the website in web browsers. The domain githubusercontent.com is designed to be separate to prevent any malicious user content from trying to steal cookies for github.com.

In general, if you're just using a web browser, click on the link or the button, and it will automatically redirect you to the right place. Otherwise, you should use the REST API to either get the raw file contents directly or fetch the download URL. Using the API will always give you the correct location and contents.

If you just want to use curl with the API and don't want to fetch the download_url key manually, you can run this: curl -H'Accept: application/vnd.github.v3.raw' https://api.github.com/repos/hasura/graphql-engine/contents/cli/get.sh.

Note also that none of these ways are designed for high-speed automated access; for that, you should host your repository on your own server with a CDN in front.