Home Dashboard Directory Help
Search

GZipStream does not seem to detect corrupt data by Andrew Teare


Status: 

Closed
 as Won't Fix Help for as Won't Fix


6
0
Sign in
to vote
Type: Bug
ID: 726860
Opened: 2/27/2012 6:48:59 PM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
1
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I'm using GZIpStream to compress / decompress data. When I wrote a unit test to make sure it could detect corrupt data (i.e., by purposely changing the compressed data in memory and then trying to decompress it), it sometimes did not detect the corrupt data (i.e., an exception was not thrown) and it returned invalid data. I posted a question on Stackoverflow (see link below) along with sample code to reproduce the problem. As far as I can tell at this point, there seems to be a problem with the GZipStream class, but please review the test case to make sure it is being used as intended.
Details
Sign in to post a comment.
Posted by Anders Sjögren on 6/12/2013 at 10:03 AM
When using built in functionality in .Net, I rely on it being decently implemented.
Compression is an important core functionality, even more so in the modern world of big data. Having half a dozen one-man hobby projects being faster, more correct, more bug-fix-responsive and reliable than important native functionality in a paid-for OS is not acceptable.

It should _really_ be fixed promptly. It's unfortunate (to be polite) that it hasn't already...

Please check http://stackoverflow.com/questions/11435200/why-does-my-c-sharp-gzip-produce-a-larger-file-than-fiddler-or-php for more info (and the high number of thumbs up for the issue).
Posted by JohannesRudolph on 3/4/2013 at 1:22 AM
Even if you're not adressing this issue in the current release, closing it as "unsolvable" is not an acceptable solution. Applications relying on GZipStream to correctly detect transmission errors cannot afford the luxury to process invalid data without detecting it.

If Microsoft is not fixing this issue, we'll have to resort using an alternative implementation and the bug should be marked "wont fix" (even though this should really be fixed since I can imagine lots of code dealing with gzip encoded HTTP is relying on this )
Posted by Microsoft on 2/21/2013 at 7:21 AM
Thank you for your feedback. We are not going to be able to address this issue in our next release due to other priorities.

Regards,
Immo Landwerth
.NET Framework team
Posted by MS-Moderator09 [Feedback Moderator] on 2/29/2012 at 2:14 AM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by MS-Moderator09 on 2/28/2012 at 1:19 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Anders Sjögren on 6/12/2013 at 10:04 AM
Use http://dotnetzip.codeplex.com/ .