From: Max Kirillov <max@max630.net>
To: Jeff King <peff@peff.net>
Cc: "Max Kirillov" <max@max630.net>,
"Junio C Hamano" <gitster@pobox.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Jelmer Vernooij" <jelmer@jelmer.uk>,
git@vger.kernel.org
Subject: Re: [PATCH] http-backend: allow empty CONTENT_LENGTH
Date: Fri, 7 Sep 2018 07:20:39 +0300 [thread overview]
Message-ID: <20180907042039.GB20545@jessie.local> (raw)
In-Reply-To: <20180907033831.GB1383@sigill.intra.peff.net>
On Thu, Sep 06, 2018 at 11:38:31PM -0400, Jeff King wrote:
> My understanding from Jelmer's report is that a present-but-empty
> variable should be counted as "0" to mean "do not read any body bytes".
> That matches my reading of RFC 3875, which says:
>
> If no data is attached, then NULL (or unset).
>
> (and earlier they explicitly define NULL as the empty string). That
> said, we do not do what they say for the "unset" case. And cannot
> without breaking chunked encoding from apache. So I don't know how much
> we want to follow that rfc to the letter, but at least it makes sense to
> me to revert this case back to what Git used to do, and what the rfc
> says.
I could find this discussion about it:
https://lists.gt.net/apache/users/373042
Basically, it says the CGI RFC was written before chunked
encoding appeared, so implementations should choose between
caching all boody before calling script, or breaking the
spec some way. So apache does it so.
(I wonder how IIS would handle it)
> In other words, I think the logic we want is:
>
> 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 CONTENT_LENGTH; trust what's in it as long as it
> * can be parsed.
> */
> if (!git_parse_ssize_t(str, &val))
> die(...);
> }
I feel reluctant to treat empty and unset differently, but
probably this is the only thing which could be done.
I'll resumbmit some time later.
next prev parent reply other threads:[~2018-09-07 4:20 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 [this message]
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 ` [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero Max Kirillov
2018-09-10 21:22 ` 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=20180907042039.GB20545@jessie.local \
--to=max@max630.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jelmer@jelmer.uk \
--cc=jrnieder@gmail.com \
--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).