Sur le serveur, je force la compression avec un gestionnaire de messages personnalisé. Le gestionnaire vérifie l'en-tête Accept-Encoding et, s'il est pris en charge (par exemple, GZip), il échange le HttpResponseMessage.Content avec une instance de CompressedContent. Cette compresse simplement le contenu original comme ceci:Lecture HttpClient personnalisée Type HttpContent
protected override async Task SerializeToStreamAsync(Stream stream, TransportContext context)
{
Ensure.Argument.NotNull(stream, "stream");
using (content) // original content
{
// creates a new GZip/Deflate stream
var compressed = GetStream(CompressionMode.Compress, stream);
await content.CopyToAsync(compressed);
compressed.Dispose();
}
}
Sur le client, nous pouvons réaliser la décompression en vérifiant l'en-tête Content-Encoding et en utilisant un autre type HttpContent pour effectuer la décompression:
protected async override Task SerializeToStreamAsync(Stream stream, TransportContext context)
{
Ensure.Argument.NotNull(stream, "stream");
using (content)
{
var compressed = await content.ReadAsStreamAsync();
var decompressed = GetStream(CompressionMode.Decompress, compressed);
await decompressed.CopyToAsync(stream);
decompressed.Dispose();
}
}
La partie I Je ne sais pas si nous devrions utiliser un type personnalisé HttpContent pour faire la décompression. Sur le serveur, il est logique de le faire car nous n'avons pas vraiment d'autre moyen de toucher le flux de réponse. Sur le client cependant, cela pourrait être fait en décompressant le StreamContent standard directement ou même avec une implémentation personnalisée HttpClient.
Je suis allé avec la suggestion de Filip d'utiliser un gestionnaire sur le client et blogué à ce sujet à http://ben.onfabrik.com/posts/aspnet-web-api-compression. –