MINOR: lua: properly process the contents of the content-length field
The header's value was parsed with atoi() then compared against -1,
meaning that all the unparsable stuff returning zero was not considered
and that all multiples of 2^32 + 0xFFFFFFFF would continue to emit a
chunk.
Now instead we parse the value using a long long, only accept positive
values and consider all unparsable values as incorrect and switch to
either close or chunked encoding. This is more in line with what a
client (including haproxy's parser) would expect.
This may be backported as a cleanup to stable versions, though it's
really unlikely that Lua applications are facing side effects of this.
diff --git a/src/hlua.c b/src/hlua.c
index d12c80b..349d372 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -4199,7 +4199,7 @@
const char *value;
int id;
int hdr_connection = 0;
- int hdr_contentlength = -1;
+ long long hdr_contentlength = -1;
int hdr_chunked = 0;
const char *reason = appctx->appctx->ctx.hlua_apphttp.reason;
@@ -4276,11 +4276,12 @@
hdr_connection = 1;
/* Copy the header content length. The length conversion
- * is done without control. If it contains a ad value, this
- * is not our problem.
+ * is done without control. If it contains a bad value,
+ * the content-length remains negative so that we can
+ * switch to either chunked encoding or close.
*/
if (strcasecmp("content-length", name) == 0)
- hdr_contentlength = atoi(value);
+ strl2llrc(value, strlen(value), &hdr_contentlength);
/* Check if the client annouces a transfer-encoding chunked it self. */
if (strcasecmp("transfer-encoding", name) == 0 &&
@@ -4313,7 +4314,7 @@
* for the keepalive compliance. If the applet annouces a transfer-encoding
* chunked itslef, don't do anything.
*/
- if (hdr_contentlength == -1 && hdr_chunked == 0 &&
+ if (hdr_contentlength < 0 && hdr_chunked == 0 &&
(appctx->appctx->ctx.hlua_apphttp.flags & APPLET_HTTP11) &&
appctx->appctx->ctx.hlua_apphttp.status >= 200 &&
appctx->appctx->ctx.hlua_apphttp.status != 204 &&