Home > Software engineering >  Unexpected HTTP GET Response from Github API
Unexpected HTTP GET Response from Github API

Time:05-21

I'm currently trying to add a simple assisted-update feature to an application I'm working on, but have hit a roadblock with the Github API when making HTTP GET requests.
I don't really have much experience with the HTTP protocol, so I apologize if the reason behind this is obvious - I couldn't find any suitable answers from other questions, so here we are.

Whenever I send a GET request to the github API from my program, it always returns the latest release version instead of the version specified in the URL.
I've tried this with a number of different URLs, which all result in the same frustratingly ironic version 4.0.4 (The latest full release version) being downloaded instead:
404-not-quite-error

Version Target URL
3.3.2 https://api.github.com/repos/radj307/volume-control/releases/assets/57436695|
5.0.0-pr4.4 https://api.github.com/repos/radj307/volume-control/releases/assets/65951248|
5.0.0-pr4.4 https://github.com/radj307/volume-control/releases/download/5.0.0-pr4.4/VolumeControl.exe

Here's the code I'm using to send the request:

using HttpClient client = new();

client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new("application/octet-stream"));
client.DefaultRequestHeaders.Add("User-Agent", "curl/7.64.1");

if (HttpDownloadFileAsync(client,
                          "https://api.github.com/repos/radj307/volume-control/releases/assets/65951248",
                          "VolumeControl.exe" //< replaced with hardcoded filename
                          ).Wait(-1)) //< using infinite timeout in debug
{
    // omitted for brevity
}
else
{
    // omitted for brevity
}
client.Dispose();

This is the HttpDownloadFileAsync function, which I got from this answer:

static async Task HttpDownloadFileAsync(HttpClient httpClient, string url, string fileToWriteTo)
{
    using HttpResponseMessage response = await httpClient.GetAsync(url, HttpCompletionOption.ResponseHeadersRead);
    using Stream streamToReadFrom = await response.Content.ReadAsStreamAsync();
    using Stream streamToWriteTo = File.Open(fileToWriteTo, FileMode.Create);
    await streamToReadFrom.CopyToAsync(streamToWriteTo);
}

To summarize:
I'm trying to download a specific prerelease version from github's API using .NET Core 6's HttpClient, and no matter what URL I use it always returned the same (incorrect) version.
I've checked in the debugger & firefox to see if the URL is correct, and it is - the API seems to decide to send back the latest release whether I want it to or not.
Why does this happen, and what can I do differently to get the correct version?

CodePudding user response:

It looks to me like you are attempting to download the API data directly, and save it as a .exe file. The URL you are passing into HttpDownloadFileAsync returns JSON data, not a .exe

If you visit the URL you are specifying in your browser, you will see the JSON output of that API, which has an element specifying the actual download link of that executable.

https://api.github.com/repos/radj307/volume-control/releases/assets/65951248:

{
  "url": "https://api.github.com/repos/radj307/volume-control/releases/assets/65951248",
  "id": 65951248,
  .. other data ..
  "browser_download_url": "https://github.com/radj307/volume-control/releases/download/5.0.0-pr4.4/VolumeControl.exe"
}

Notice at the bottom this result gives you a "browser_download_url". You can either replace the url in HttpDownloadFileAsync with the given URL, or if you need to retrieve it from that URL specifically, for whatever reason, you must first download that JSON content and retrieve that browser_download_url value, passing it into HttpDownloadFileAsync.

I hope this helps your problem

CodePudding user response:

I decided to go ahead with embedding the executable anyway since I couldn't get this to work, and somehow that fixed it.
It was broken when running the program directly through Visual Studio's debugger, and now that it's being called outside of the debugger it works fine without any changes.

Therefore, I'm blaming MS.

  • Related