Re: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
- Date: Mon, 10 Sep 2018 14:22:21 -0700
- From: Jonathan Nieder <jrnieder@xxxxxxxxx>
- Subject: Re: [PATCH] http-backend: Treat empty CONTENT_LENGTH as zero
Max Kirillov wrote:
> From: Jeff King <peff@xxxxxxxx>
> 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
> Signed-off-by: Max Kirillov <max@xxxxxxxxxx>
> 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
const char *str = getenv("CONTENT_LENGTH");
if (!str || !*str)
if (!git_parse_ssize_t(str, &val))
That would match the RFC, but it seems to make t5510-fetch.sh hang,
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)
++ 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?