0
byte[] httpDecompress(HttpDatagram http)
    {
        int magicnum = 0x1f8b;
        Stream str= http.Body.ToMemoryStream();
        using (var zipStream = new GZipStream(str, CompressionMode.Decompress))
        using (var resultStream = new MemoryStream())
        {
            zipStream.CopyTo(resultStream);
            return resultStream.ToArray();
        }
    }

there is the code but it gives a magic number error. How can i find the beginning of the GZip string, i think the source of problem is there. Can anyone help?

Gökberk Açıkgöz
  • 3
  • 1
  • 5
  • What is a "gzip string"? – Lasse V. Karlsen May 23 '17 at 11:34
  • The error _"The magic number in GZip header is not correct"_ means you're dealing with a non-Zip file, or the file is corrupt. – CodeCaster May 23 '17 at 11:36
  • I am trying to get HTTP body data from a TCP packet. It's transfer encoding type is Gzip. I'm converting it to memory stream and trying to decompress it. Gives a wrong magic number error i think because it doesn't gets the right beginning point. – Gökberk Açıkgöz May 23 '17 at 11:38
  • You can't just start unzipping from a random packet, you'll have to start at the beginning of the stream. – CodeCaster May 23 '17 at 11:41
  • 1
    A TCP packet doesn't have a transfer encoding. An HTTP response has a transfer encoding, and an HTTP response will be comprised of many packets. The fact that you are confusing different layers of the stack probably means that you need to go back to basics to get to the bottom of what's going on. – spender May 23 '17 at 11:41
  • @CodeCaster yeah it's my question how can i find the beginning of this stream. – Gökberk Açıkgöz May 23 '17 at 11:47
  • @spender I'm listening on a website, packets are coming from a site, so it includes HTTP response body and header.It's ok with header but body seems to be compressed. – Gökberk Açıkgöz May 23 '17 at 11:49
  • @CodeCaster I'm using pcap.net library i got a HttpDatagram i get the data from there. – Gökberk Açıkgöz May 23 '17 at 11:52

1 Answers1

0

Not knowing where the gzip stream starts may or may not be your problem. (In fact, probably not.) In any case, you can search for the three-byte sequence 1f 8b 08 to identify candidate gzip streams. Start decompressing from the 1f to see if it really is a gzip stream.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Ok thanks. With which method can help me with searching the whole 1460 byte data? – Gökberk Açıkgöz May 23 '17 at 14:01
  • @GökberkAçıkgöz What you have (at best) is incomplete data. 1460 is likely to be the size of a packet (it's a very common packet size, and the term HttpDatagram is a big giveaway here...). You need to step away from inspecting packets and get/assemble the entire HTTP response beyond the double carriage return that signifies the end of the headers. You can't just pick out 1460 (or less) bytes from a GZipped response and throw it at a decoder. It doesn't work like that. You need the ***entire*** response body. – spender May 23 '17 at 16:54
  • Oh thanks, can you help me with assembling the entire body? – Gökberk Açıkgöz May 23 '17 at 19:39