Re: [PATCH] http-backend: allow empty CONTENT_LENGTH

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

> 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(...);
>   }