The client actually sends Accept-Encoding: deflate, gzip[CR][LF]. This gets replaced by the <strippart> bit to Accept-Encoding: xxx[LF] - the .* matches, and removes, the carriage return. However, the <protocol> section compensates for this by omitting the carriage return from the expected client message, only on that Accept-Encoding line. I've taken a photo to make this clear - the ^M is a carriage return.
This is mostly ok, except that runtests.pl then calls subNewlines on Accept-Encoding: xxx[LF], which restores the carriage return and fails the test, for Hyper specifically.
I think the fix is to make the strippart matching better - match on a space character, a comma, or [a-zA-Z], but don't match on carriage returns, and then modify the <protocol> bits to include the carriage return, which is what actually gets sent by the client.
The text was updated successfully, but these errors were encountered:
Thanks! I agree with the analysis and fix. I could easily make test 221 work with this:
diff --git a/tests/data/test221 b/tests/data/test221
index ce80637b1..2d769bcc7 100644
--- a/tests/data/test221+++ b/tests/data/test221@@ -53,18 +53,18 @@ http://%HOSTIP:%HTTPPORT/%TESTNUMBER --compressed
# Verify data after the test has been "shot"
-s/^Accept-Encoding: .*/Accept-Encoding: xxx/+s/^Accept-Encoding: [a-zA-Z, ]*/Accept-Encoding: xxx/
GET /%TESTNUMBER HTTP/1.1
I'll work on applying this on more Accept-Encoding tests and then do a PR...