Possible for HttpClient to send content or body for GET request?

Question

Currently to send a parameterized GET request to an API interface I am writing the following code:

api/master/city/filter?cityid=1&citycode='ny'

But I see that there is a limit on the URL length of 2,083 characters.

To avoid this I would like to send the parameters in json format in the content body for a GET request.

However, I see that none of the Get methods for the HttpClient allow for a content body to be sent. For the POST I could see there is a method within HttpClient named PostAsync that allows for a content body.

Is there a way to send parameters for a GET request not in the URL in order to avoid the URL length limit?

Answer 1

Please read the caveats at the end of this answer as to why HTTP GET requests with bodies are, in general, not advised.

---

• If you are using .NET Core, the standard HttpClient can do this out-of-the-box. For example, to send a GET request with a JSON body:

  HttpClient client = ...
  
  ...
  
  var request = new HttpRequestMessage
  {
      Method = HttpMethod.Get,
      RequestUri = new Uri("some url"),
      Content = new StringContent("some json", Encoding.UTF8, ContentType.Json),
  };
  
  var response = await client.SendAsync(request).ConfigureAwait(false);
  response.EnsureSuccessStatusCode();
  
  var responseBody = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
  

• .NET Framework doesn't support this out-of-the-box (you will receive a ProtocolViolationException if you try the above code). Thankfully Microsoft has provided the System.Net.Http.WinHttpHandler package that does support the functionality - simply install and use it instead of the default HttpClientHandler when constructing your HttpClient instances:

  var handler = new WinHttpHandler();
  var client = new HttpClient(handler);
  
  <rest of code as above>
  

  Reference: https://github.com/dotnet/corefx/issues/28135#issuecomment-467261945

---

Caveats:

• HTTP GET with a body is a somewhat unconventional construct that falls in a gray area of the HTTP specification - the end result is that many older pieces of software either cannot handle such a request at all, or will explicitly reject it because they believe it to be malformed. You need to make very sure that the endpoint you're trying to send such a request to does support it, or at best you will get an HTTP error code back; at worst the body will be silently discarded. This can lead to some head-scratching debugging!
• Caching proxy servers, again particularly older ones, may cache GET requests based only on the URL because they don't expect a body to be present. This could either result in the least recent request being cached forever (which will break your software), or that the only request ever cached is the most recent one issued (which will prevent caching from working as intended). Again, this can be very painful to figure out.