Comment 1:

Labels changed: added release-go1.3.

Comment 2:

Labels changed: removed go1.3.

Comment 3:

Labels changed: added repo-main.

Comment 4:

This requires API changes. Probably too late for Go 1.3. (It was also too late for Go
1.2 when it was proposed, though, and is arguably already "started" since a patch
exists).
Russ?

Comment 5:

Yes, I guess so. Best laid plans and all.

Labels changed: added release-go1.4, removed release-go1.3.

Comment 6:

Is the started CL available for this? If it's not going into 1.3, I'd like to be able to
work on a fork that is likely to match what goes into the standard so that when it does
it is not much more than a import change.

Comment 7:

Sorry, that is obviously the diff quoted at
https://groups.google.com/d/msg/golang-dev/nA3QRGIvrOE/cXv7ygTsU8IJ. What I'm interested
in knowing is if the change that comes is likely to be in line with what was tentatively
proposed there. I am asking because I have been holding off work on my package waiting
for this issue, so now that it looks like if will possibly be another three to six
months (depending on how the release cycle is dealt with this round), I don't think I
can wait for the standard library any more.

Comment 8:

I assumed you had forked the package already. Please do.

Comment 9:

To answer your original question, I don't know what the API will be like. My message is
one option, but I'm not 100% thrilled with it. If I were sure that was the right API I
would just do it now.

Comment 10:

Thanks, Russ. I should clarify. I have a fork that uses my approach to handling the
member header to deal with blocked decoding, but maintaining this while bringing in
changes from compress/gzip (and keeping public-facing types and fields interoperable
with that package) while not difficult it painful.
I was hoping to retire that fork when the fix for this issue and the (otherwise
unrelated) CL13512052 goes in,  before moving on to deal with the long term
implementation of the BGZF reader which will be doing partially parallel blocked read
ahead with block caching. This requires careful handling of gzip member header fields
that I'm only just able to keep my head around in a stable world, changing API is likely
to blow away my capacity to handle that.

Comment 11:

I have come back to this code since I have found some time with clear thought. I can now
see that I can achieve exactly what I want to do with the API as is stands at the
moment. Apologies for confusion.
To explain, the current gzip.Reader Read() method returns with a nil error without
filling the parameter slice when the call to z.decompressor.Read(p) reads across a
member boundary (because err != io.EOF since the decompressor return nil here). In my
case I intend to already know the start of the next member, so a gzip.Reader Reset() on
the underlying Reader Seek'd to the appropriate location will give me the next Header.
The upshot is that a test of n < len(p) && err == nil will tell you if you have
reached a boundary. 
After a brief reading of the WARC format mentioned by Daniel Krech in the original
thread, I think they should also be able to use this approach.

Comment 12:

That doesn't sound like a reliable test. An io.Reader is always allowed to return fewer
bytes than requested.
Future code changes may break your test.

Comment 13:

That's true, but the flate.Reader can't read through to the next member since there are
non-flate components to be handled and it could be specified in the gzip docs that a
single Read will not cross a member boundary, formalising the current behaviour.

Comment 14:

Sorry, you're right Brad; my tests pass due to their small size. Working with real data,
I can guarantee they will fail since the flate.decompressor hist is half as long as the
block size I am using.

Comment 15:

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

Comment 16:

This issue was closed by revision 70f2f1b.

Status changed to Fixed.