A simple fix would be to always store the error returned by z.decompressor.read:

diff --git a/src/compress/zlib/reader.go b/src/compress/zlib/reader.go
index 78ea704..640089f 100644
--- a/src/compress/zlib/reader.go
+++ b/src/compress/zlib/reader.go
@@ -94,8 +94,10 @@ func (z *reader) Read(p []byte) (n int, err error) {

    n, err = z.decompressor.Read(p)
    z.digest.Write(p[0:n])
-   if n != 0 || err != io.EOF {
+   if (err != nil) {
        z.err = err
+   }
+   if n != 0 || err != io.EOF {
        return
    }

I'm not certain, if the io.Read() interface guarantees that calls after the first one that returned EOF should also return EOF, but returning "unexpected EOF" is definitely unexpected.

The io.Reader interfaces guarantees nothing about any calls past the first error, but I suppose this is fixable, especially if behavior changes from Go 1.5 to Go 1.6.

I'll fix this. There's another unrelated bug here. The zlib package doesn't reset z.err when Reset is called.

Adding the following line to @AsamK's example still reports io.ErrUnexpectedEOF:

reader.(zlib.Resetter).Reset(bytes.NewReader(compress.Bytes()), nil)
fmt.Println(reader.Read(buf[:])) // 0 unexpected EOF

CL https://golang.org/cl/20292 mentions this issue.

Thanks for fixing this so quickly, will the fix be included in a 1.6.1 release?

No promises, but we'll consider it.

@rsc, @ianlancetaylor, @adg, this was a regression from Go 1.4 and Go 1.5 and presumably earlier. Maybe a candidate for Go 1.6.1.

Related is #14676

Not sure this is critical enough for 1.6.1. Is it breaking something important that can't be changed not to read multiple times at EOF or to use a fixed copy of the library?

Also, @bradfitz's fix in #14676 could easily be applied by the user as well.

This is unfortunate but a big change. The mime instance was the main trigger and we have a simpler mime fix for 1.6.2.