From: Max Kirillov <max@max630.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Jelmer Vernooij" <jelmer@jelmer.uk>,
"Florian Manschwetus" <manschwetus@cs-software-gmbh.de>,
"Max Kirillov" <max@max630.net>
Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
Date: Mon, 10 Sep 2018 23:53:59 +0300 [thread overview]
Message-ID: <20180910205359.32332-1-max@max630.net> (raw)
In-Reply-To: <20180910052558.GB55941@aiede.svl.corp.google.com>
From: Jeff King <peff@peff.net>
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 <max@max630.net>
---
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
next prev parent reply other threads:[~2018-09-10 20:54 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f12bc1d7-6acb-6ad9-2917-fbb09105f87a@debian.org>
[not found] ` <20180905202613.GA20473@blodeuwedd>
2018-09-06 6:10 ` CONTENT_LENGTH can no longer be empty Jonathan Nieder
2018-09-06 19:35 ` [PATCH] http-backend: allow empty CONTENT_LENGTH Max Kirillov
2018-09-06 21:54 ` Junio C Hamano
2018-09-07 3:27 ` Max Kirillov
2018-09-07 3:38 ` Jeff King
2018-09-07 4:20 ` Max Kirillov
2018-09-07 4:59 ` Max Kirillov
2018-09-07 9:49 ` Junio C Hamano
2018-09-08 5:41 ` Max Kirillov
2018-09-09 4:40 ` Max Kirillov
2018-09-06 22:45 ` Jonathan Nieder
2018-09-07 3:36 ` [PATCH v2] " Max Kirillov
2018-09-08 0:19 ` Jonathan Nieder
2018-09-08 5:35 ` Max Kirillov
2018-09-08 5:42 ` [PATCH v3] " Max Kirillov
2018-09-10 5:17 ` Jonathan Nieder
2018-09-10 20:36 ` Max Kirillov
2018-09-11 4:06 ` Jonathan Nieder
2018-09-11 20:33 ` [PATCH v2] http-backend test: make empty CONTENT_LENGTH test more realistic Max Kirillov
2018-09-09 4:10 ` [PATCH v4] http-backend: allow empty CONTENT_LENGTH Max Kirillov
2018-09-10 5:25 ` Jonathan Nieder
2018-09-10 13:17 ` Jeff King
2018-09-10 16:37 ` Junio C Hamano
2018-09-10 18:46 ` Jeff King
2018-09-10 20:53 ` Max Kirillov [this message]
2018-09-10 21:22 ` [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero Jonathan Nieder
2018-09-11 1:55 ` Jeff King
2018-09-11 2:20 ` Jonathan Nieder
2018-09-11 2:30 ` Jeff King
2018-09-11 1:58 ` Jeff King
2018-09-11 3:42 ` [PATCH] http-backend: treat " Jonathan Nieder
2018-09-11 4:03 ` Jonathan Nieder
2018-09-11 18:15 ` Junio C Hamano
2018-09-11 18:27 ` Junio C Hamano
2018-09-12 5:56 ` Jeff King
2018-09-12 6:26 ` Jonathan Nieder
2018-09-12 16:10 ` Junio C Hamano
2018-09-11 4:18 ` Junio C Hamano
2018-09-11 4:29 ` Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180910205359.32332-1-max@max630.net \
--to=max@max630.net \
--cc=git@vger.kernel.org \
--cc=jelmer@jelmer.uk \
--cc=jrnieder@gmail.com \
--cc=manschwetus@cs-software-gmbh.de \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).