REST APIs Response Header: UTF8 vs UTF-8 vs Blank

Hi,

We have been importing information from many APIs using Azure Data Factory. The charset ‘utf8’ from the response header content-type is not supported because it should be ‘utf-8’ with a hyphen.

We discovered this issue while trying to import data from interactions.

Would it be possible to fix it/remove it for interactions?

/qm/interactions returns:
content-type: application/json; charset=utf8

/contact_center/engagements returns:
content-type: application/json

/report/operationlogs returns:
content-type: application/json;charset=UTF-8

Hi @dalzamendi
Thanks for reaching out to us!
Can you confirm that this is only happening with this endpoint:
/qm/interactions ?

Or do you see this issue in other endpoints too?

We only see that inconsistency it in that endpoint (interactions) for now, we have done work with other endpoints like:
agents_time_sheets
dispositions
engagements
flows
queues
queues_details
queues_metrics
users
voice_calls
operations

and haven’t had any issues.

There seems to be other issues with this endpoint.

  1. Max page limit in the documentation is 300. But when executing:
    {{baseUrl}}/qm/interactions?to=2024-11-31T23:59:59Z&from=2024-11-01T00:00:00Z&page_size=101

       We get the error:
       {
           "status": false,
           "errorCode": 0,
           "errorMessage": "Internal Server Error",
           "result": null
       }
    
  2. There appears to be a cap of 10,000 records. For example, in October, we have significantly more than 10,000 records, but the query:

    /qm/interactions?to=2024-10-31T23:59:59Z&from=2024-10-01T00:00:00Z&page_size=100

    Only returns 10,000

    Same with November and any other months.

Hey @dalzamendi
I will send you a DM so you can share more information about this
Follow up accordingly please

Adding one more inconsistency for this endpoint:

It seems that the ‘duration’ column is returning the duration rounded to minutes, rather than in seconds, which is the normal value across other endpoints

Hi @dalzamendi
I confirmed with our Engineering team that the response header issue is not a bug but a field returned uniformly by the OpenAPI Gateway, so there is no optimization for us to make here.
I am still looking into the duration field

Hi,

Thanks for the feedback. My point is that UTF-8 is the correct encoding name, not UTF8. There are .NET libraries that will not identify UTF8 as a valid encoding name. It just doesn’t make sense, especially when all the other endpoints don’t have this problem.

I understand David and I will re share this with our team

1 Like

Hi, I was seeking an update please on the UTF-8 issue, we have implemented a work around, but it is running into other issues failing our loads. We are seeking call this API the same manner as others which work ok, as they are not impacted by this UTF8 / UTF-8 anomaly. Thanks Keith

Can we please get an update on this issue.

@dalzamendi I alerted Zoom support of this problem back in December 2016 (yes, you read that right: 8 1/2 years ago!). I had discovered that some of their endpoints returned the misspelled utf8 charset name instead of the correct spelling which, as you pointed out, is utf-8. After some back and forth, the support person who was helping me said that their engineering team declared they were not going to fix the problem because some programing languages are able to overlook this misspelling and automatically fallback to utf-8. In their opinion, it didn’t matter that the HttpClient class in .NET was rejecting the invalid value and throwing an exception.

This is a problem in .NET when you invoke the ReadAsStringAsync method of the HttpClient class because it tries to automatically determine how the content was encoded and tries to use the appropriate encoding to convert the payload back into a string. This logic breaks when the http response contains an invalid and/or misspelled charset name because the misspelled value does not correspond to any known encoding. In this scenario, Microsoft’s HttpClient throws an exception because it doesn’t know how to handle this unknown charset name.

Because Zoom is not likely to ever resolve this problem (someone please correct me if I am assuming incorrectly), you need to look for an alternative and let me suggest two:

Suggestion number 1:
You can use the ReadAsStreamAsync method of the HttpClient class and try to determine the encoding by yourself in order to convert the content of the stream into a string. You would basically be recreating the logic of Microsoft’s ReadAsStringAsync except you would contend with the aforementioned misspelling and implement a fallback logic when you discover an invalid charset name.

Suggestion number 2:
Instead of trying to resolve the problem yourself, I recommend you use ZoomNet which is an open source .NET client for the Zoom API (disclaimer: I’m the author). This “misspelled charset name” problem is automatically handled for you in this library using the logic I described in my previous suggestion, so you no longer have to worry about this specific problem. There are many other benefits to using this library but I am only highlighting this one because it is specifically relevant to the problem you are facing.

Let me know if any of this is useful to you

@Keith2 I meant to tag you as well in my answer above. Sorry about that.