{ "WorkItem": { "AffectedComponent": { "Name": "", "DisplayName": "" }, "ClosedComment": "Not a bug in Ionic.Zlib . ", "ClosedDate": "2011-08-06T18:23:30.533-07:00", "CommentCount": 0, "Custom": null, "Description": "I have a stream being compressed (on the server side) with the Noemax compression component. I am trying out the Ionic.Zlib.GZipStream on the client. I've found there is one file when passed compressed causes Ionic.Zlib.GZipStream to throw an exception during Close/Dispose. I can't seem to reproduce this with any other file. The exception comes from finish() in ZlibBaseStream.cs:\n \n throw new ZlibException(String.Format(\"Protocol error. AvailableBytesIn={0}, expected 8\", _z.AvailableBytesIn + bytesRead));\n \nAvailable bytes is 4, and the code is at the end of the stream. Now the content has been decompressed correctly (I have a sha256 of the content and it verifies) and this happens when Dispose is called automatically as a using() block is cleaning up. It looks like finish needs to be called so that you can throw for bad crc's and wrong lengths. But given the data is 'ok', I'm not sure what to do here. \n \nThe stream appears to decompress fine with the system libraries (and the neomax libraries of course). One interesting thing is the stream lenght, it's 65536*2 which given it's magic number status may be relivant.\n \nCould there be an option to disable crs/size checking at close/dispose?", "LastUpdatedDate": "2013-05-16T05:31:44.463-07:00", "PlannedForRelease": "", "ReleaseVisibleToPublic": false, "Priority": { "Name": "Low", "Severity": 50, "Id": 1 }, "ProjectName": "DotNetZip", "ReportedDate": "2010-09-03T10:51:44.137-07:00", "Status": { "Name": "Closed", "Id": 4 }, "ReasonClosed": { "Name": "Unassigned" }, "Summary": "Exception on Dispose", "Type": { "Name": "Issue", "Id": 3 }, "VoteCount": 2, "Id": 11870 }, "FileAttachments": [], "Comments": [ { "Message": "I concur and have a related bug (#12554). Throwing an exception on Dispose() seems to be an awkward implementation. Perhaps create an explicit method for this CRC/Size check - or an option to enable/disable this as suggested here.", "PostedDate": "2010-11-23T09:15:46.393-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2011-06-16T20:24:14.13-07:00", "Id": -2147483648 }, { "Message": "This workitem asks for a modification to the Ionic GZipStream, to allow it to not throw an exception when given invalid input (lacking a complete and accurate GZIP trailer). \r\n\r\nThis would be a reasonable request, if it were fairly common to get GZIP input that is invalid in this way, but otherwise valid, as in your case. A defacto standard, if you know what I mean. But it seems to be a quite rare occurrence. It has happened in 2 cases: bsobel's special case, and also a broken WCF example published on the internet. In the latter case, the correct approach was (is) to fix the WCF example to utilize the GZIP protocol correctly, thereby avoiding the exception in the Ionic.Zlib.GZipStream as it reads. I believe that is the correct approach in bsobel's case also. \r\n\r\nI have never seen another case where the gzip stream is invalid in this way. If there were a common, popular tool or program that persistently produced broken GZIP output, and there was no way to get that tool or program to conform to the spec, then there might be an argument for other libraries to conform to the broken behavior. But that's not the case here. \r\n\r\nYou've reported that the system libraries and the neomax libraries both pass the broken GZIP stream. As far as I can tell, the System.IO.Compression.GZipStream, when used in decompression, always punts on checking the CRC and isize, which I think is sloppy and wrong. There's a reason the GZIP spec included a CRC. I don't know how the neomax libraries are implemented, but if it punts on CRC validation, once again I think that is wrong. Data integrity is not something to be neglected. I don't believe \"the other guys do it\" is a good justification for supporting incorrect behavior. \r\n\r\nThe Ionic GZIP Stream is implemented correctly, and checks the CRC and ISize as required by the specification described in RFC 1952. The exception you've encountered is correct and expected given the broken input you've presented to the Ionic stream. \r\n\r\nYou pointed out that there is no problem with the data - that your own SHA256 check on the stream verifies. But of course there's no way for the GZipStream to know that. GZIP has a built-in, formally specified data integrity check feature - the CRC - and the GZipStream uses that feature. In your particular case, with one file, the CRC fails because the data is truncated. Inconvenient, but true. Sounds like a bug on your end.\r\n\r\nRegarding the comments pertaining to the appropriateness or \"awkwardness\" of throwing from within the context of the Dispose() method. The Ionic.Zlib.GZipStream checks the CRC according to the spec, at the appropriate time in the GZipStream life cycle. You can see that is the correct place from which to throw, given that the check for the CRC and ISize must occur after all input is read. \r\n\r\nI understand it is awkward for an application implementer when the CRC fails, but that is a problem of data, not a problem with the GZipStream. I do think the exception message is lame, and I will fix that. \r\n\r\nSo I'm going to reject this change request. I think the stream behaves correctly, as is. The justification offered here to allow non-compliant behavior is not sufficient to warrant a change, in my opinion. \r\n\r\n", "PostedDate": "2011-08-06T18:21:50.857-07:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2011-08-06T18:23:30.533-07:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-02-21T18:43:27.17-08:00", "Id": -2147483648 }, { "Message": "", "PostedDate": "2013-05-16T05:31:44.463-07:00", "Id": -2147483648 } ] }