git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] remote-curl: die on server-side errors

From
Josh Steadmon <steadmon@google.com>
Date
Nov 15, 2018, 21:51 UTC
Message-ID
<20181115215152.GK126896@google.com>
In-Reply-To
<20181114070052.GA19904@sigill.intra.peff.net>
On 2018.11.14 02:00, Jeff King wrote:
Show 29 quoted lines
> On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote:
> 
> > Yes, the packet_read_line_buf() interface will both advance the buf
> > pointer and decrement the length.  So if we want to "peek", we have to
> > do so with a copy (there's a peek function if you use the packet_reader
> > interface, but that might be overkill here).
> > 
> > You can rewrite it like this, which is a pretty faithful conversion and
> > passes the tests (but see below).
> > [...]
> 
> Here's a version which is less faithful, but I think does sensible
> things in all cases, and is much easier to follow. I get a little
> nervous just because it tightens some cases, and one never knows if
> other implementations might be relying on the looseness. E.g.:
> 
>   - in the current code we'd still drop back to dumb http if the server
>     tells us "application/x-git-upload-pack" but the initial pktline
>     doesn't start with "#" (even though if it _does_ have "#" at
>     position 5 but isn't a valid pktline, we'd complain!)
> 
>   - right now the v2 protocol does not require the server to say
>     "application/x-git-upload-pack" for the content-type
> 
> This patch tightens both of those (I also made a few stylistic tweaks,
> and added the ERR condition to show where it would go). I dunno. Part of
> me sees this as a nice cleanup, but maybe it is better to just leave it
> alone. A lot of these behaviors are just how it happens to work now, and
> not part of the spec, but we don't know what might be relying on them.

At least according to the protocol-v2 and http-protocol docs, the stricter behavior seems correct:

For the first point above, dumb servers should never use an "application/x-git-*" content type (http-protocol.txt line 163-167).

For the second point, the docs require v2 servers to use "application/x-git-*" content types. protocol-v2.txt lines 63-65 state that v2 clients should make a smart http request, while http-protocol.txt lines 247-252 state that a smart server's response type must be "application/x-git-*".

Of course we don't know if other implementations follow the spec, but ISTM that this patch at least doesn't contradict how we've promised the protocols should work.

If no one has any objections, I'll include the diff below in v2. Thanks for the help Jeff!

Show 116 quoted lines
> diff --git a/remote-curl.c b/remote-curl.c
> index 762a55a75f..1adb96311b 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -330,9 +330,61 @@ static int get_protocol_http_header(enum protocol_version version,
>  	return 0;
>  }
>  
> +static void check_smart_http(struct discovery *d, const char *service,
> +			     struct strbuf *type)
> +{
> +	char *src_buf;
> +	size_t src_len;
> +	char *line;
> +	const char *p;
> +
> +	if (!skip_prefix(type->buf, "application/x-", &p) ||
> +	    !skip_prefix(p, service, &p) ||
> +	    strcmp(p, "-advertisement"))
> +		return;
> +
> +	/*
> +	 * We speculatively try to read a packet, which means we must preserve
> +	 * the original buf/len pair in some cases.
> +	 */
> +	src_buf = d->buf;
> +	src_len = d->len;
> +	line = packet_read_line_buf(&src_buf, &src_len, NULL);
> +	if (!line)
> +		die("invalid server response; expected service, got flush packet");
> +
> +	if (skip_prefix(line, "# service=", &p) && !strcmp(p, service)) {
> +		/*
> +		 * The header can include additional metadata lines, up
> +		 * until a packet flush marker.  Ignore these now, but
> +		 * in the future we might start to scan them.
> +		 */
> +		while (packet_read_line_buf(&src_buf, &src_len, NULL))
> +			;
> +
> +		/*
> +		 * v0 smart http; callers expect us to soak up the
> +		 * service and header packets
> +		 */
> +		d->buf = src_buf;
> +		d->len = src_len;
> +		d->proto_git = 1;
> +
> +	} else if (starts_with(line, "version 2")) { /* should be strcmp()? */
> +		/*
> +		 * v2 smart http; do not consume version packet, which will
> +		 * be handled elsewhere.
> +		 */
> +		d->proto_git = 1;
> +	} else if (skip_prefix(line, "ERR ", &p)) {
> +		die(_("remote error: %s"), p);
> +	} else {
> +		die("invalid server response; got '%s'", line);
> +	}
> +}
> +
>  static struct discovery *discover_refs(const char *service, int for_push)
>  {
> -	struct strbuf exp = STRBUF_INIT;
>  	struct strbuf type = STRBUF_INIT;
>  	struct strbuf charset = STRBUF_INIT;
>  	struct strbuf buffer = STRBUF_INIT;
> @@ -405,38 +457,8 @@ static struct discovery *discover_refs(const char *service, int for_push)
>  	last->buf_alloc = strbuf_detach(&buffer, &last->len);
>  	last->buf = last->buf_alloc;
>  
> -	strbuf_addf(&exp, "application/x-%s-advertisement", service);
> -	if (maybe_smart &&
> -	    (5 <= last->len && last->buf[4] == '#') &&
> -	    !strbuf_cmp(&exp, &type)) {
> -		char *line;
> -
> -		/*
> -		 * smart HTTP response; validate that the service
> -		 * pkt-line matches our request.
> -		 */
> -		line = packet_read_line_buf(&last->buf, &last->len, NULL);
> -		if (!line)
> -			die("invalid server response; expected service, got flush packet");
> -
> -		strbuf_reset(&exp);
> -		strbuf_addf(&exp, "# service=%s", service);
> -		if (strcmp(line, exp.buf))
> -			die("invalid server response; got '%s'", line);
> -		strbuf_release(&exp);
> -
> -		/* The header can include additional metadata lines, up
> -		 * until a packet flush marker.  Ignore these now, but
> -		 * in the future we might start to scan them.
> -		 */
> -		while (packet_read_line_buf(&last->buf, &last->len, NULL))
> -			;
> -
> -		last->proto_git = 1;
> -	} else if (maybe_smart &&
> -		   last->len > 5 && starts_with(last->buf + 4, "version 2")) {
> -		last->proto_git = 1;
> -	}
> +	if (maybe_smart)
> +		check_smart_http(last, service, &type);
>  
>  	if (last->proto_git)
>  		last->refs = parse_git_refs(last, for_push);
> @@ -444,7 +466,6 @@ static struct discovery *discover_refs(const char *service, int for_push)
>  		last->refs = parse_info_refs(last);
>  
>  	strbuf_release(&refs_url);
> -	strbuf_release(&exp);
>  	strbuf_release(&type);
>  	strbuf_release(&charset);
>  	strbuf_release(&effective_url);
Previous: Jeff KingNext: Jeff King
Message 10 of 41 in “remote-curl: die on server-side errors”
  1. remote-curl: die on server-side errorssteadmon@google.com, Nov 12, 2018
  2. Stefan BellerNov 12, 2018
  3. Junio C HamanoNov 13, 2018
  4. Junio C HamanoNov 13, 2018
  5. Josh SteadmonNov 13, 2018
  6. Jeff KingNov 13, 2018
  7. Josh SteadmonNov 13, 2018
  8. Jeff KingNov 14, 2018
  9. Jeff KingNov 14, 2018
  10. Josh SteadmonNov 15, 2018
  11. 0/3 remote-curl smart-http discovery cleanupJeff King, Nov 16, 2018
  12. 1/3 remote-curl: refactor smart-http discoveryJeff King, Nov 16, 2018
  13. Josh SteadmonNov 16, 2018
  14. Junio C HamanoFeb 5, 2019
  15. Jeff KingFeb 6, 2019
  16. 1/3 remote-curl: refactor smart-http discoveryJeff King, Feb 6, 2019
  17. Josh SteadmonFeb 6, 2019
  18. Junio C HamanoFeb 6, 2019
  19. Jeff KingFeb 6, 2019
  20. 2/3 remote-curl: tighten "version 2" check for smart-httpJeff King, Feb 6, 2019
  21. 3/3 t5551: test server-side ERR packetJeff King, Feb 6, 2019
  22. Junio C HamanoFeb 6, 2019
  23. 2/3 remote-curl: tighten "version 2" check for smart-httpJeff King, Nov 16, 2018
  24. Josh SteadmonNov 16, 2018
  25. 3/3 remote-curl: die on server-side errorsJeff King, Nov 16, 2018
  26. Josh SteadmonNov 16, 2018
  27. 0/4 Unify pkt-line error handling and refactor smart-httpJosh Steadmon, Dec 12, 2018
  28. 1/4 pack-protocol.txt: accept error packets in any contextJosh Steadmon, Dec 12, 2018
  29. Jeff KingDec 12, 2018
  30. Masaya SuzukiDec 13, 2018
  31. Jeff KingDec 13, 2018
  32. Josh SteadmonDec 13, 2018
  33. Jeff KingDec 17, 2018
  34. Josh SteadmonDec 19, 2018
  35. Jeff KingDec 20, 2018
  36. 2/4 remote-curl: refactor smart-http discoveryJosh Steadmon, Dec 12, 2018
  37. 3/4 remote-curl: tighten "version 2" check for smart-httpJosh Steadmon, Dec 12, 2018
  38. 4/4 lib-httpd, t5551: check server-side HTTP errorsJosh Steadmon, Dec 12, 2018
  39. Junio C HamanoDec 12, 2018
  40. Junio C HamanoNov 13, 2018
  41. Josh SteadmonNov 13, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.