From: Max Kirillov Date: Mon, 10 Sep 2018 20:53:59 GMT Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero Message-ID: <20180910205359.32332-1-max@max630.net> In-Reply-To: <20180910052558.GB55941@aiede.svl.corp.google.com> From: Jeff King Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero There is no known case where empty body it used by a server as instruction to read until EOF, so there is no need to violate the RFC. Make get_content_length() return 0 in this case. Currently there is no practical difference, as the GET request where it can be empty is handled without actual reading the body (in get_info_refs() function), but it is better to stick to the correct behavior. Signed-off-by: Max Kirillov --- The incremental. Hopefully I described the reason right. Needs "signed-off-by" http-backend.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/http-backend.c b/http-backend.c index 458642ef72..ea36a52118 100644 --- a/http-backend.c +++ b/http-backend.c @@ -353,8 +353,28 @@ static ssize_t get_content_length(void) ssize_t val = -1; const char *str = getenv("CONTENT_LENGTH"); - if (str && *str && !git_parse_ssize_t(str, &val)) - die("failed to parse CONTENT_LENGTH: %s", str); + if (!str) { + /* + * RFC3875 says this must mean "no body", but in practice we + * receive chunked encodings with no CONTENT_LENGTH. Tell the + * caller to read until EOF. + */ + val = -1; + } else if (!*str) { + /* + * An empty length should be treated as "no body" according to + * RFC3875, and this seems to hold in practice. + */ + val = 0; + } else { + /* + * We have a non-empty CONTENT_LENGTH; trust what's in it as long + * as it can be parsed. + */ + if (!git_parse_ssize_t(str, &val)) + die("failed to parse CONTENT_LENGTH: '%s'", str); + } + return val; } -- 2.17.0.1185.g782057d875