0

I am issuing a POST request through the HttpClient class and reading the response. It works about 90% of the time, but sometimes the response string is {} and the endpoint I am hitting behaves as though it was issued a DELETE request with the same parameters as my POST request. This is my code

while (true)
{
    HttpContent content = new FormUrlEncodedContent(new Dictionary<string, string>());
    string fliptUrl = _fliptUrl + flag;
    var response = _http.PostAsync(fliptUrl, content).Result;
    if (!response.IsSuccessStatusCode)
    {
        continue;
    }
    string responseString = response.Content.ReadAsStringAsync().Result;
    Console.WriteLine(responseString);
    if (responseString.Equals("404 page not found\n"))
    {
        throw new HttpRequestException("Flipt returned 404");
    } else if (responseString.Equals("{}"))
    {
        continue;
    }

Why would this be happening? Am I handling the asynchronous nature of the HttpClient in a weird way that is resulting in this behavior?

The print statement shown usually prints out {"key":"asdf","name":"asdf","description":"asdf","enabled":true,"createdAt":"2019-08-09T18:59:37.926184281Z","updatedAt":"2019-08-09T18:59:37.926184281Z"} and in the edge case I am encountering it prints {}

Zachary Oldham
  • 838
  • 1
  • 5
  • 21
  • You should use async/await instead of blocking by using `Result`. Other than that, I cant imagine a case in which using `HttpClient#PostAsync` could behave like `HttpClient#DeleteAsync` – Jota.Toledo Aug 09 '19 at 19:10
  • Why is async/await preferred over `Result`? This method needs to behave synchronously for my use case, or least needs to be able to be called synchronously. – Zachary Oldham Aug 09 '19 at 19:12
  • Depending on the context it might have undesired effects to block the thread. – Jota.Toledo Aug 09 '19 at 19:19
  • Await vs result: https://stackoverflow.com/questions/24623120/await-on-a-completed-task-same-as-task-result – Caius Jard Aug 09 '19 at 19:20
  • 1
    You code looks like it batters the remote endpoint as fast as the loop will let it. Are you sure the empty response you're getting back "that looks like a delete" isn't simply a case of the server encountering some error and failing out on you? Use a web debugging proxy, like Fiddler, to examine the emitted request and the empty response pairing – Caius Jard Aug 09 '19 at 19:22
  • @CaiusJard I would say that you may be right, but when I started encountering this issue I implemented the same POST request in python and ran it as fast as I could, and not only did I not get this issue, I didn't get any error responses from the endpoint even though the code I post actually gets other errors aside from this one from the endpoint as well. – Zachary Oldham Aug 09 '19 at 19:29
  • You are getting that response from the server though, so this is behavior of the API. It probably either should have returned a non-success statuscode, or maybe it is returning a 202 accepted response status, and the resource is not yet available until later. Or it is a bug in the API. – Jesse de Wit Aug 09 '19 at 20:42

0 Answers0