-1

My research says that this is a bad thing to do. Content-Type is explicitly intended for use with messages that have content, eg. POST, PUT, and (maybe?) PATCH.

Unfortunately, another team at my company decided that they would require Content-Type on all HTTPS requests made to their REST API, and the chances of that changing are close to nil, even though this violates RFC 7231 Section 3.1.5.5.

(For reference, they decided that "Content-Type" would be used to specify which version of their API the call expects to use.)

When I try to do

HttpClient myHttpClient = new HttpClient() //code simplified for brevity

myHttpClient.DefaultRequestHeaders.Add("Content-Type", "application/json; version=3.0");

I get a runtime exception:

Misused Header Name

When I try:

myHttpClient.DefaultRequestHeaders.TryAddWithoutValidation("Content-Type", "application/json; version=3.0");

The Content-Type header doesn't seem to get added.

What can I do?

Catachan
  • 190
  • 2
  • 12
  • 2
    `Content-Type` applies to the request body, so it shouldn't be sent if there's no content (empty content has no content type), regardless of the verb you use. If you want to indicate what kind of response you expect, send the `Accept` header. – madreflection Apr 04 '23 at 18:20
  • _"I get a runtime exception."_ - please add the exception text. – Guru Stron Apr 04 '23 at 18:22
  • 1
    I would not that [this answer](https://stackoverflow.com/a/45034136/2557128) suggests you should add the header to each `HttpRequestMessage` and not to `HttpClient`. – NetMage Apr 04 '23 at 20:30

3 Answers3

0

It turns out that dotnet really wants you to respect HTTP. It actually blocks you from creating Content-Type headers onto GET requests. I traced through the dotnet source and found a method that explicitly checks to make sure that your request is a response type header.

Thankfully, I also discovered that the other team at my company had implemented the Accept header for use in defining the API version, though that behavior was not documented anywhere.

Unfortunately, I don't think this answer will be of much use to others beyond the discovery that dotnet 6.0 explicity blocks the Content-Type header from GET requests.

Catachan
  • 190
  • 2
  • 12
-1

I highly recommend against this, but I don't see a way to mis-use the allowed headers using HttpRequestHeaders. TryAddWithoutValidation doesn't actually skip validating that the header is acceptable when it is a standard, well-known header.

So, you can use Reflection to cheat:

var hr = myHttpClient.DefaultRequestHeaders;
var customProp = typeof(HttpRequestHeaders).BaseType.GetField("_treatAsCustomHeaderTypes", BindingFlags.NonPublic|BindingFlags.Instance);
var cpVal = (byte)customProp.GetValue(hr);
customProp.SetValue(hr, (byte)(cpVal | 0b1000)); // add the Content headers to the custom header types so they will be allowed
hr.Add("Content-Type", "application/json; version=3.0");
customProp.SetValue(hr, cpVal); // reset to original only Response headers as custom headers

Note that the best answer is probably to add the header to each HttpRequestMessage instead.

NetMage
  • 26,163
  • 3
  • 34
  • 55
-2

this syntax is the most common, it was used thousand time and working properly. The only thing is I am not sure that you really you need it. Json is an accept format by default

var contentType = new MediaTypeWithQualityHeaderValue("application/json");
httpClient.DefaultRequestHeaders.Accept.Add(contentType);
Serge
  • 40,935
  • 4
  • 18
  • 45