Sendgrid-csharp: Contacts API fails with Content-Type application/json; charset=utf-8

[dustinmoris]

Making a request to the Contacts API endpoint ({baseUrl}/marketing/contacts) with a Content-Type of application/json; charset=utf-8 returns a 400 Bad Request saying that the content type is not supported:

{
    "errors": [
        {
            "field": "content-type",
            "message": "invalid content-type: application/json; charset=utf-8"
        }
    ]
}

You can try it out yourself at https://sendgrid.com/docs/API_Reference/api_v3.html and send a PUT request to the Contacts endpoint.

Unfortunately this C# client ALWAYS sets the charset to UTF8, which makes it unusable for some endpoints like the one above. Can the SendGrid folks please accept the entirely valid media type with the charset or at least make it optional in the RequestAsync method of the client?

Feels really broken right now and is frustrating that I've spend a couple hours trying to understand why a valid request gets denied for appending the charset -.-

If I send the same request with just application/json (without the utf-8 charset) then the request succeeds, but that has to be done manually and can't be done with the RequestAsync method at the moment.

[thinkingserious]

Thanks for reporting this @dustinmoris,

We've added this to our backlog for further investigation.

With best regards,

Elmer

[shaunroot]

Is there a workaround for this using the SendGrid client or should I just drop it and use the standard RestClient?

[dustinmoris]

@shaunroot I ended up just using the plain HttpClient in .NET Core for now, but looking at the code I believe you could just use this constructor and pass in your own request headers with your own ContentType, which I think will override the default Content-Type.

I haven't tested this though, just my feeling by briefly looking at the code!

[shaunroot]

@dustinmoris Thanks. I just tossed SendGrid-csharp entirely and did simple REST calls. It's much less of a headache.

[hallidev]

I can't believe this is an issue nearly four months after being reported.

For a hack, add this on line 231 of SendGridClient.cs:

if (request.Content != null) { request.Content.Headers.ContentType.CharSet = string.Empty; }

I have no idea if this breaks any other API calls.

This needs to be fixed on your server. It doesn't seem like an earth shattering change. Why has it not been addressed? The fact that API calls fail with your own client is unacceptable.

[marius-stanescu]

Any updates on this?

[fpavlic]

Any updates?

[childish-sambino]

Closing this as the consensus is that this is a server-side issue that the client shouldn't need a workaround/hack to resolve. Recommend contacting support to investigate a back-end fix.

[dustinmoris]

@childish-sambino Are you guys not working for the same company? Is https://github.com/sendgrid/sendgrid-csharp not part of the company SendGrid? If it is, then consider this issue the support ticket. If it's in the wrong repo then please move it into the correct (private?) repo where it belongs?

[hallidev]

@childish-sambino I'm wondering the same thing. Isn't this Sendgrid's official client for C#?

[childish-sambino]

@dustinmoris Yes, this repo is part of Twilio SendGrid, but issues here are only monitored by the engineering team responsible for managing the repo itself. For account, request, and API-specific issues, only support is able to help.

[childish-sambino]

@hallidev Yes, this is the official C# client, but as the issue is with the API itself it is not something that should/can be resolved here.

[hallidev]

Then please open up an internal ticket. We're paying customers and shouldn't have to hunt down people to fix this. That support link you gave is literally laughable. I'm honestly offended if you think someone could start with that link and end with a code change to your API.

You have to be kidding me.

[VagueGit]

@dustinmoris and @hallidev make a good point. Paying customers should not be told to find the appropriate support person within an organisation. Departments within an organisation should not tell paying customers 'not my problem'. If paying customers raise an issue, getting that issue fixed should not be the customer's problem.

I see this time and again on this repo and it is not a good look for Twilio/SendGrid

[hallidev]

Funny enough, your comment and my SendGrid bill just showed up side by side in my email

[marius-stanescu]

Thinking of switching to MailChimp ...

[dustinmoris]

@childish-sambino Maybe my first response was a bit tongue in cheek. I was thinking since the consensus is that this is a server-side issue it doesn't have to be a customer who raises that ticket internally, right? It could be just your team, which maintains the C# client to raise that ticket saying that your client's tests are failing because the server has a bug and then assign it to the server side team? After all you all work towards the same goal I'd be thinking, making SendGrid great, right?

[childish-sambino]

Ah, able to recreate this locally. Checking with support.

[childish-sambino]

Best I can tell is that the default charset for JSON is utf-8, so including this in the content type is not necessary. But, still, it should not be rejected. I'll update the existing PR to check if the media type is the default (json) and, if so, not drop the charset. This will at least unblock usage in this repo. Will follow-up when I have an backend engineering response/ticket.

[hallidev]

@childish-sambino Thank you. I apologize for getting harsh yesterday. Appreciate the follow up.