[NOT FOR MERGE] test with 1.1.0-M1-RC1

[pjfanning]

testing the RC

[pjfanning]

I brought back the change that was in #539 and found that HeaderDecompression only works with ByteArrayInputStream. The legacy code always converted the ByteString to ByteArrayInputStream. The PR539 code can return a SequenceInputStream for byte strings that are made up of multiple smaller byte strings.

I tried the failing tests and the InputStreams have the same contents whether we force the use of ByteArrayInputStream or use the new ByteString.asInputStream code that can return ByteArrayInputStream or SequenceInputStream.

I think the issue is in the hpack (Twitter lib). Its Decoder uses available calls to see if there are more bytes. I have found that available is not reliable in all InputStream implementations. Most of the time, you just call read and stop reading when you get a -1 result.

https://github.com/twitter/hpack/blob/master/hpack/src/main/java/com/twitter/hpack/Decoder.java

If you look at SequenceInputStream, you'll see that available() can return 0 when you have read through one of its underlying InputStreams but haven't yet moved on the next stream.

[He-Pin]

Cool!