Re: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 10, 2018, 21:22 UTC
Message-ID: <20180910212221.GG26356@aiede.svl.corp.google.com>
In-Reply-To: <20180910205359.32332-1-max@max630.net>

Hi,

Max Kirillov wrote:

> From: Jeff King <peff@peff.net>
> Subject: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero

micronit: s/Treat/treat/

Show 12 quoted lines

> 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"

Thanks.  I am wondering if we should go all the way and do

	ssize_t val;
	const char *str = getenv("CONTENT_LENGTH");

	if (!str || !*str)
		return 0;
	if (!git_parse_ssize_t(str, &val))
		die(...);
	return val;

That would match the RFC, but it seems to make t5510-fetch.sh hang, right after

  ok 165 - --negotiation-tip understands abbreviated SHA-1

When I run with -v -i -x, it stalls at

  ++ git -C '/usr/local/google/home/jrn/src/git/t/trash directory.t5510-fetch/httpd/www/server' tag -d alpha_1 alpha_2 beta_1 beta_2
  Deleted tag 'alpha_1' (was a84e4a9)
  Deleted tag 'alpha_2' (was 7dd5cf4)
  Deleted tag 'beta_1' (was bcb5c65)
  Deleted tag 'beta_2' (was d3b6dcd)
  +++ pwd
  ++ GIT_TRACE_PACKET='/usr/local/google/home/jrn/src/git/t/trash directory.t5510-fetch/trace'
  ++ git -C client fetch --negotiation-tip=alpha_1 --negotiation-tip=beta_1 origin alpha_s beta_s

Do you know why?

Thanks, Jonathan