net/docs/filter.md

The network stack implements support for Content-Encodings using
"source streams", which can be composed together and mutate all the incoming
bytes from a URLRequestJob. Currently, the following streams are implemented:

* gzip (handling "deflate" and "gzip" Content-Encodings)
* brotli (handling "br" Content-Encoding)

Source streams conceptually form a chain, with the URLRequestJob as both the
beginning and end of the chain, meaning the URLRequestJob produces raw bytes at
the end and consumes unencoded bytes at the beginning. For example, to support a
hypothetical "Content-Encoding: bar,foo", streams would be arranged like so,
with "X <-- Y" meaning "data flows from Y to X", "X reads data from Y", or
"X is downstream from Y".

  URLRequestJob <-- BarSourceStream <-- FooSourceStream <-- URLRequestJob
                                                       (URLRequestSourceStream)

Here URLRequestJob pulls filtered bytes from its upstream, BarSourceStream,
which pulls filtered bytes from FooSourceStream, which in turn pulls raw bytes
from URLRequestJob. URLRequestSourceStream is the ultimate upstream, which
produces the raw data. Every stream in the chain owns its upstream. In this
case, the ultimate downstream, URLRequestJob, owns its upstream,
BarSourceStream, which in turn owns FooSourceStream. FooSourceStream owns its
upstream, URLRequestSourceStream.

All source streams conform to the following interface (named SourceStream in the
tree):

  int Read(IOBuffer* dest_buffer, size_t buffer_size,
           const OnReadCompleteCallback& callback);

This function can return either synchronously or asynchronously via the supplied
callback. The source stream chain is "pull-based", in that data does not
propagate through the chain until requested by the final consumer of the
filtered data.