You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just opening the discussion to enable end-to-end support for gzip compression for the .NET Client for Azure Search.
Sample calling code:
var response = await _indexClient.Documents.GetWithHttpMessagesAsync<T>(id, new List<string>() { "*" }, new SearchRequestOptions(), new Dictionary<string, List<string>>()
{
{"Accept-Encoding", new List<string>(){ "gzip", "deflate"}}
}, cancellationToken);
Its ugly, but it does instruct the client to bring down the data gzip'd.
The problem is that the .NET Client always assumes the response will be a string response, as per:
The code you've pointed out is generated by the AutoRest tool. Any fix would need to originate there. I suggest opening an issue in the Azure/autorest repo.
Just opening the discussion to enable end-to-end support for gzip compression for the .NET Client for Azure Search.
Sample calling code:
Its ugly, but it does instruct the client to bring down the data gzip'd.
The problem is that the .NET Client always assumes the response will be a string response, as per:
https://github.com/Azure/azure-sdk-for-net/blob/psSdkJson6/src/SDKs/Search/DataPlane/Microsoft.Azure.Search/GeneratedSearchService/DataSourcesOperations.cs#L296
The client needs to check for the Content-Encoding header, and if gzip, handle it appropriately.
Thanks.
The text was updated successfully, but these errors were encountered: