PSDK throws an exception when reading response headers

We are using the .NET Platform SDK .
We are currently using version 207.0.0 of the PSDK library.

When testing our program (a .NET Fat Client) at the customer site, we encounter following error:

All API calls our client makes after login will cause an Exception to be thrown.
We are using the asynchronous methods, so the stacktraces will look like this:

System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.ArgumentException: Ein Element mit dem gleichen Schlüssel wurde bereits hinzugefügt.
bei System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
bei System.Collections.Generic.Dictionary2.Insert(TKey key, TValue value, Boolean add) bei System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable1 source, Func2 keySelector, Func2 elementSelector, IEqualityComparer`1 comparer)
bei PureCloudPlatform.Client.V2.Client.ApiClient.d__35.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
bei PureCloudPlatform.Client.V2.Api.UsersApi.d__197.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei PureCloudPlatform.Client.V2.Api.UsersApi.d__196.MoveNext()
--- Ende der internen Ausnahmestapelüberwachung ---

(The target system uses German language, thus the German error texts).

As I can gleam from this exception, PSDK tries to add new data to a C# Dictionary - but the key is already there.
When I look into the source code of the PSDK, I see 2 places where this is done:

  • First in the method UsersApi::GetUsersMeAsyncWithHttpInfo(). This method takes the HTTP headers from the response and convert them into a Dictionary indexed by the header name.
  • Second also before, in the method ApiClient::CallApiAsync - this method is called by the previous method. Here the response headers are also converted to a Dictionary for logging in the SDK log file.
    • This SDK logging was also activated by us, for better error tracing.

As the same code is used in both locations, the exception seems to come from the second one in the "CallApiAsync" method, as this is called before the other.
The bug in this method is that HTTP headers can occur more than once in a HTTP response.
According to RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, a header can occur more than once in the response, and the client must be able to handle that, if and only if
the value of that header is a list of data.
PSDK does not seem to do that, however, as the "ToDictionary" method of any collection will fail if the collection has non-unique keys!

This error does not occur at our site, also not when accessing the customer's cloud account from our own machines, but only when the code runs on the customer systems.
These systems are isolated from the Internet via proxy, so it is possible that the proxy may manipulate the headers of the response. We cannot influence that, however.

Did anyone else encounter this problem? It is quite serious for us, as it prevents us from making any API calls.

If you have reason to suspect a flaw in the client SDK you should open an incident with customer care to get it properly analyzed and routed to the correct team.

We opened a ticket, but got no definite answer yet.

Hi,

Thank you for the deep analysis of the issue. It helps tremendously. Can you drop the ticket # you opened with the post? I will have someone from my team take a look at it. It almost seems like a proxy/Secure Services Gateway is adding a duplicate request header. You might want to talk to your client's networking team and see if they are doing anything related

I will get someone from my team to look at this and see if we can provide a fix. As a workaround, you can always call the REST APIs directly. Our wrappers are very thin wrappers around the REST API. It's not an ideal solution, but it will allow you to unblock while we sort this out.

Thanks,
John Carnell
Director, Developer Engagement

Hi,
the case number is Case #0003541089.
Thanks,
Wolfgang Liebich

Hi Wolfgang,

I just talked to one of my engineers. He is wrapping up another bug and this will be the next item on the plate. I don't have an ETA on this, but its been prioritized and will be looked at.

Thanks,
John Carnell
Directory, Developer Engagement

Hi Wolfgang,

We have a PR up for this issue. Once we have reviewed it and it has gone through testing it should be merged. I am hoping this will be done by sometime early next week. Please watch the ticket for updates.

Thanks,
John

Hi, John,
Thanks for the update - due to an illness I have only seen it today.
This fix is very important for us, because it is a complete blocker for one of our projects .
Thanks,
Wolfgang

Hello,

The fix should be in version 214.0.0 which has been released yesterday.

Regards,

OK, thanks, we will update our dependency and re-test it then.

Regards,
Wolfgang

Thanks, the fix solved our problem.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.