git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eric Wong <e@80x24.org>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH] http-backend: buffer headers before sending
Date: Wed, 10 Aug 2016 09:27:14 -0700	[thread overview]
Message-ID: <xmqqlh047fod.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160809234731.GA10310@dcvr> (Eric Wong's message of "Tue, 9 Aug 2016 23:47:31 +0000")

Eric Wong <e@80x24.org> writes:

> diff --git a/http-backend.c b/http-backend.c
> index 0d59499..adc8c8c 100644
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -75,55 +75,57 @@ static void format_write(int fd, const char *fmt, ...)
>  	write_or_die(fd, buffer, n);
>  }
>  
> -static void http_status(unsigned code, const char *msg)
> +static void http_status(struct strbuf *hdr, unsigned code, const char *msg)
>  {
> -	format_write(1, "Status: %u %s\r\n", code, msg);
> +	strbuf_addf(hdr, "Status: %u %s\r\n", code, msg);
>  }

The idea is to pass "struct strbuf *hdr" around the callchain to
helpers so that they can all append into it instead of doing
format_write(), which is sensible.  This pattern continues quite a
bit (omitted).

> -static void end_headers(void)
> +static void end_headers(struct strbuf *hdr)
>  {
> -	write_or_die(1, "\r\n", 2);
> +	strbuf_add(hdr, "\r\n", 2);
> +	write_or_die(1, hdr->buf, hdr->len);
> +	strbuf_release(hdr);
>  }

Then end_headers() is taught to drain the buffered headers.  The
helpers used by other helpers in the next level of abstraction that
emit the header and the body also need to take the buffer as their
parameter, like this one:

> -static void send_strbuf(const char *type, struct strbuf *buf)
> +static void send_strbuf(struct strbuf *hdr,
> +			const char *type, struct strbuf *buf)
>  {
> -	hdr_int(content_length, buf->len);
> -	hdr_str(content_type, type);
> -	end_headers();
> +	hdr_int(hdr, content_length, buf->len);
> +	hdr_str(hdr, content_type, type);
> +	end_headers(hdr);
>  	write_or_die(1, buf->buf, buf->len);
>  }

because their caller already has something to say in the header
part.

> +static int bad_request(struct strbuf *hdr, const struct service_cmd *c)
> +{
> +	const char *proto = getenv("SERVER_PROTOCOL");
> +
> +	if (proto && !strcmp(proto, "HTTP/1.1")) {
> +		http_status(hdr, 405, "Method Not Allowed");
> +		hdr_str(hdr, "Allow",
> +			!strcmp(c->method, "GET") ? "GET, HEAD" : c->method);
> +	} else
> +		http_status(hdr, 400, "Bad Request");
> +	hdr_nocache(hdr);
> +	end_headers(hdr);
> +	return 0;
> +}
> +

This is like other helpers that respond with 4xx, e.g. forbidden(),
but it did not exist only because there was a single callsite that
needed this feature, which made it open-coded directly in main().
It was somewhat surprising to see a new helper, because the only
thing this patch changes logically is where the output is sent, but
this is a very sensible refactoring.

>  int cmd_main(int argc, const char **argv)
>  {
>  	char *method = getenv("REQUEST_METHOD");
> ...
> @@ -659,18 +681,8 @@ int cmd_main(int argc, const char **argv)
>  		if (!regexec(&re, dir, 1, out, 0)) {
>  			size_t n;
>  
> -			if (strcmp(method, c->method)) {
> -				const char *proto = getenv("SERVER_PROTOCOL");
> -				if (proto && !strcmp(proto, "HTTP/1.1")) {
> -					http_status(405, "Method Not Allowed");
> -					hdr_str("Allow", !strcmp(c->method, "GET") ?
> -						"GET, HEAD" : c->method);
> -				} else
> -					http_status(400, "Bad Request");
> -				hdr_nocache();
> -				end_headers();
> -				return 0;
> -			}
> +			if (strcmp(method, c->method))
> +				return bad_request(&hdr, c);

... and this is where it came from.  It could have been a separate
"preparatory cleanup" step, but it is so trivial that "while at it"
clean-up is perfectly fine.

Thanks, will queue.


      parent reply	other threads:[~2016-08-10 21:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-09 23:47 [PATCH] http-backend: buffer headers before sending Eric Wong
2016-08-10 12:32 ` Jeff King
2016-08-10 20:36   ` Eric Wong
2016-08-10 16:27 ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqlh047fod.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).