From 820ffb96b1a7ce6ab8412649e976b9dae703267a Mon Sep 17 00:00:00 2001 From: Richard Bradfield Date: Wed, 12 Oct 2022 09:35:16 +0100 Subject: [PATCH] content-encoding: fix Gzip test on non-linux hosts The output test for Gzip encoding uses a hardcoded expected value, however the Gzip header is unstable containing both a timestamp and an OS ID field. The timestamp field is apparently not set by the `deflate` crate but the OS ID is, meaning this test consistently fails on systems other than x86_64 Linux. Here we just change the test to ignore the 10-byte header, rather than trying to hack together a proper round-trip test in the absence of a decoder method in the library crate. --- src/content_encoding.rs | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/content_encoding.rs b/src/content_encoding.rs index 9c142be53..a4ac63886 100644 --- a/src/content_encoding.rs +++ b/src/content_encoding.rs @@ -309,13 +309,18 @@ mod tests { .0 .read_to_end(&mut encoded_content) .unwrap(); + + // The 10-byte Gzip header contains an OS ID and a 4 byte timestamp + // which are not stable, so we skip them in this comparison. Doing a + // literal compare here is slightly silly, but the `deflate` crate has + // no public decompressor functions for us to test a round-trip assert_eq!( - encoded_content, + encoded_content[10..], vec![ - 31, 139, 8, 0, 0, 0, 0, 0, 0, 3, 179, 201, 40, 201, 205, 177, 179, 201, 72, 77, 76, - 177, 179, 41, 201, 44, 201, 73, 181, 243, 72, 205, 201, 201, 87, 40, 207, 47, 202, - 73, 177, 209, 135, 8, 217, 36, 229, 167, 84, 218, 217, 20, 160, 202, 21, 216, 217, - 232, 67, 36, 244, 193, 166, 0, 0, 202, 239, 44, 120, 76, 0, 0, 0 + 179, 201, 40, 201, 205, 177, 179, 201, 72, 77, 76, 177, 179, 41, 201, 44, 201, 73, + 181, 243, 72, 205, 201, 201, 87, 40, 207, 47, 202, 73, 177, 209, 135, 8, 217, 36, + 229, 167, 84, 218, 217, 20, 160, 202, 21, 216, 217, 232, 67, 36, 244, 193, 166, 0, + 0, 202, 239, 44, 120, 76, 0, 0, 0 ] ); // Applied proper gzip encoding }