From: Daniel Stenberg <daniel@haxx.se>
Date: Tue, 22 Apr 2003 22:32:02 +0000 (+0000)
Subject: Dan Fandrich's gzip bugfix
X-Git-Tag: curl-7_10_5~73
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c95814c04d6a0436e5c4c88d2e1d57c7e0c91060;p=curl

Dan Fandrich's gzip bugfix
---

diff --git a/lib/content_encoding.c b/lib/content_encoding.c
index 9705c009c..92152cdf7 100644
--- a/lib/content_encoding.c
+++ b/lib/content_encoding.c
@@ -33,7 +33,7 @@
 #include <curl/types.h>
 #include "sendf.h"
 
-#define DSIZ 4096               /* buffer size for decompressed data */
+#define DSIZ 0x10000             /* buffer size for decompressed data */
 
 #define GZIP_MAGIC_0 0x1f
 #define GZIP_MAGIC_1 0x8b
@@ -248,7 +248,12 @@ Curl_unencode_gzip_write(struct SessionHandle *data,
       break;
 
     case GZIP_UNDERFLOW:
-      /* We need more data so we can find the end of the gzip header */
+      /* We need more data so we can find the end of the gzip header.
+      It's possible that the memory block we malloc here will never be
+      freed if the transfer abruptly aborts after this point.  Since it's
+      unlikely that circumstances will be right for this code path to be
+      followed in the first place, and it's even more unlikely for a transfer
+      to fail immediately afterwards, it should seldom be a problem. */
       z->avail_in = nread;
       z->next_in = malloc(z->avail_in);
       if (z->next_in == NULL) {