Correct handling of filter chaining of SDCH and gzip compression

When a first filter (gzip) has buffered internal data to process, and has
already pushed a full 32K buffer to a second filter (such as sdch), but
the second filter declined to output anything (and instead asserted it
needed more data), then the filter chain was returning FILTER_OK.  That
status usually meant that the filter should be called again, but the 
calling code decided that a return of no bytes without a FILTER_NEED_MORE_DATA
status must mean the filter was done.

Rather than trying to change the calling infrastructure (which could impact
existing filters than are not part of a chain), this patch ensures that the 
chained sequence never returns FILTER_OK without providing some output data.  
This matches semantics of individual filters, which only return FILTER_OK 
when they have pushed some data into the output buffer.

bug=1609306
r=huanr,openvcdiff
Review URL: http://codereview.chromium.org/19459

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8944 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions