[Versioned Clients][API Notifications] Fails to read new versions when available

[chamweer]

[Versioned Clients][API Notifications] Fails to read new versions when available

[commonsensesoftware]

I see what happened. I'll consider this a bug.

Honestly, this feels like a bug in System.Net.Http, but I doubt I'll move the mountain much if I file an issue. I'm not sure why, but I'm willing to bet if I go down in the implementation far enough, I'll find that comma-separated values are only handled in some cases (🤷🏽‍♂️ no idea why).

The ApiVersionEnumerator is actually doing the right thing, but HttpHeaders.TryGetValues is not. By spec, any multi-value HTTP header (most are) can be listed multiple times:

api-supported-versions: 0.9
api-supported-versions: 1.0

or collapsed into a single header:

api-supported-versions: 0.9, 1.0

provided there is no change in meaning. If the headers are listed multiple times, then HttpHeaders.GetValues and HttpHeaders.TryGetValues will do the correct thing. If the header values are collapsed into one, then those methods are retrieving a single string value without splitting them. This is why ApiVersionEnumerator isn't reporting the correct results. In fact, multiple, multi-value headers are even allowed:

api-supported-versions: 0.9, 1.0
api-supported-versions: 2.0, 2.1

There are various reasons why the server might do that. In reviewing the tests, I don't have any scenarios that cover these cases. The solution is pretty straight forward. I'll work on getting a fix out.

Thanks for reporting it and providing a comprehensive repro. It's very helpful.

[chamweer]

Glad I could help identify the issue. As you mentioned, the current implementation of the HttpHeaders extension methods does not support splitting comma-separated values, leading to invalid behaviour.

Thanks again for acknowledging the report!