fix data pollution issue

[lingmingyb]

The data buffer should be copied in advance in case _currentReadOp->_buffer being polluted(This bug can be reproduced easily using a single NSURLConnection App).

I thought #23 was related with this issue.

[goaway]

Waiting to copy until just before the client call was intentional, since we shouldn't need to copy if it's compressed data that will just need to be written to another buffer anyways.

There's not supposed to be a way for the original underlying buffer to change until the call to [_delegate didReadDataFrame:frame frameDecoder:self] returns (at which point the data should have been copied or fully handled). This is the part that's eluding me. How is the underlying buffer changing?

Can you explain further what you're seeing or provide steps to reproduce? If there's a deeper issue I want to make sure it's addressed.

[goaway]

Ugh. Okay here's the deeper issue: [data copy] isn't a copy. Of course. This was a relatively recent change, and the simple answer is to do an actual copy of the buffer there.

[goaway]

Thank you very much for the pull request; I've made a commit that still allows the copy to be deferred, but actually ensures the underlying bytes are copied before passing them off to the client.

[lingmingyb]

#22 #23 can be closed since this is the reason leading to them.