#4105 bogus CRC mismatches in ::http::Gunzip on 64bit architecture

[Matthias Kraft]

Hi *,

[binary scan i] delivers signed integers, while [zlib crc32] delivers unsigned integers. The appended patch will correct the crc from binary scan.

Simple test case: create gzipped data that delivers such a CRC, i.e.

$ dd if=/dev/zero bs=1 count=128 | gzip -1 > 128zeros.gz

then run this small script:

----

package r http 2.7

set fh [open 128zeros.gz r]
fconfigure $fh -encoding binary -translation binary
set data [read $fh]
close $fh

::http::Gunzip $data

----

Result without patch:

invalid data: checksum mismatch -1029113187 != 3265854109
while executing
"::http::Gunzip $data"

kind regards
-- Matthias Kraft

[Matthias Kraft]

Correcting signed CRCs

[Pat Thoyts]

Logged In: YES
user_id=202636
Originator: NO

The problem is treating the crc and size fields in the gzip header as signed when they should be unsigned. Fixed simply by using binary scan $header iuiu crc size to use them as unsigned values.
Committed to HEAD and 8.5 branch (not relevant to 8.4)

[Don Porter]

Logged In: YES
user_id=80530
Originator: NO

This has been fixed in http 2.7.1.

Is the bug also present in http 2.5.5 ?
If so, is there any reasonable way to fix it
to make an http 2.5.6 that can still be
used in a Tcl 8.4 interp?

[Don Porter]

Logged In: YES
user_id=80530
Originator: NO

For the sake of the ActiveTcl
8.4 distributions that support
Tcl Modules, an http 2.7.1 that
fixes this bug and doesn't rely
on Tcl 8.5 would be a good idea.

Without that, AT 8.4 will continue
to get buggy http 2.7 by default.

[Pat Thoyts]

Logged In: YES
user_id=202636
Originator: NO

OK. making use of the binary scan like this isn't necessary so changed to apply a 32bit mask in the comparison instead which remains 8.4 compliant.