This repository has been archived by the owner on Sep 9, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 55
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
28 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a68c7e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess
System.Net.Http.HttpContent.TryComputeLength
should be more appropriate, but since it´s protected a wrapper ``HttpContent` could be used expose this method.Or simply ignore content length since GzipStream doesn´t need to know the length of the stream to be compressed(correct me if i´m wrong)
a68c7e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ahmedalejo that computation is in place for the client to know the number of total bytes that the request's response is going to have, in advance. That let's browsers (for example) display a progress bar while downloading data. It has nothing to do with the actual compression.
a68c7e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CheloXL i´m aware of that. The case is that in CompressedContent.SerializeToStreamAsync we always do
instead of
which makes
await response.Content.LoadIntoBufferAsync();
superfluous and using more memory.ContentLengthKnown(HttpResponseMessage response)
isn´t considering the response´sContent-Length
headera68c7e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also doing
await response.Content.LoadIntoBufferAsync()
in messageHandler doesn´t allow you implement a customICompressor
that wants to do streaming (i.e no In-Memory buffer, or at least not a big one)