The brotli decoder is not fully streamed - it has an internal ring buffer and in most cases when that is not full it will not produce output. This is a bit different than zib which will produce output anytime possible. That means that the final bits of brotli decompressed content need to be triggered from the compressed onStopRequest which indicates to the brotli lib that the input is complete. Furthermore if that call generates an error (because the buffered data is not valid brotli) the channel needs to have its status updated to the same error code that will be delivered to the stream listener's onstoprequest (that's a property the test suite checks for). over in 366559 I did that by having nsHTTPCompressConv::OnStopRequest (which is called from the stack after httpchannel::onstoprequest) call channel->cancel before calling the streamlistener->onstoprequest. So that seemed to go ok, but it turns out that there can be mutliple uses of the same channel with the decoder. Specifically, the mime "sniffer" peeks at some of the channel data, and calls onstart/oda/onstop with the first block of it, all independently of the normal content consumer stream. it uses the same request channel however.. so in the case of some brotli documents that meant that the sniffer onstop received an error code (truncated invalid brotli because it only used the first block) but that also resulted in the channel being cancel'd, which meant the normal full content stream also received an error incorrectly.
Created attachment 8669829 [details] [diff] [review] cancel brotli failures from channel instead of converter
Created attachment 8670288 [details] [diff] [review] cancel brotli failures from channel instead of converter
https://hg.mozilla.org/integration/mozilla-inbound/rev/dd2d80b9b98584c652d61ae08dff290e00cd46f6 bug 1211580 - cancel brotli failures from channel instead of converter r=bagder