tree 4597624626b466bfae46c776975e5ee83f12dca4
parent 3706e1754b925e56951b604cce63f3bb290ed838
author Willy Tarreau <w@1wt.eu> 1691571754 +0200
committer Willy Tarreau <w@1wt.eu> 1692030822 +0200
encoding latin1

BUG/MINOR: http: skip leading zeroes in content-length values

Ben Kallus also noticed that we preserve leading zeroes on content-length
values. While this is totally valid, it would be safer to at least trim
them before passing the value, because a bogus server written to parse
using "strtol(value, NULL, 0)" could inadvertently take a leading zero
as a prefix for an octal value. While there is not much that can be done
to protect such servers in general (e.g. lack of check for overflows etc),
at least it's quite cheap to make sure the transmitted value is normalized
and not taken for an octal one.

This is not really a bug, rather a missed opportunity to sanitize the
input, but is marked as a bug so that we don't forget to backport it to
stable branches.

A combined regtest was added to h1or2_to_h1c which already validates
end-to-end syntax consistency on aggregate headers.

(cherry picked from commit 22731762d9fe2c98d9e6c3942b1568266b23c69f)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit c33738c7d4ed50e1758dbedd39dfe5bd929a5076)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 84462c9390c3efe95b748bb9fc3bd2edc3decd2f)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit e2e464018fda41758bd42d3bcd6ac623c88a110e)
[wt: applied the http.c to h2.c]
Signed-off-by: Willy Tarreau <w@1wt.eu>