| OLD | NEW |
| (Empty) | |
| 1 The network stack implements support for Content-Encodings using "filters", |
| 2 which can be composed together and mutate all the incoming bytes from a |
| 3 URLRequestJob. Currently, the following filters are implemented: |
| 4 |
| 5 * gzip (handling "deflate" and "gzip" Content-Encodings) |
| 6 * sdch (handling "sdch" Content-Encoding) |
| 7 * brotili (handling "br" Content-Encoding) |
| 8 |
| 9 Filters conceptually form a chain, with the URLRequestJob as both the beginning |
| 10 and end of the chain, meaning the URLRequestJob produces raw bytes at the |
| 11 beginning and consumes filtered bytes at the end. For example, to support a |
| 12 hypothetical "Content-Encoding: bar,foo", filters would be arranged like so, |
| 13 with "X --> Y" meaning "Y reads bytes from X": |
| 14 |
| 15 URLRequestJob --> FooFilter --> BarFilter --> URLRequestJob |
| 16 |
| 17 Here the URLRequestJob pulls filtered bytes from BarFilter, which pulls filtered |
| 18 bytes from FooFilter, which in turn pulls raw bytes from the URLRequestJob. |
| 19 |
| 20 All filters conform to the following interface (named StreamSource in the tree): |
| 21 |
| 22 net::Error Read(IOBuffer* dest_buffer, size_t buffer_size, size_t *bytes_read, |
| 23 const OnReadCompleteCallback& callback); |
| 24 |
| 25 This function can return either synchronously or asynchronously via the supplied |
| 26 callback. The filter chain is "pull-based", in that data does not propagate |
| 27 through the filter chain until requested by the final consumer of the filtered |
| 28 data. |
| OLD | NEW |