Re: [PATCH/RFC] Allow curl to rewind the RPC read buffer

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2009, 17:49 UTC
Message-ID: <7vzl62zisy.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.00.0912011232450.5582@cone.home.martin.st>

Martin Storsjö <martin@martin.st> writes:

> As long as the current rpc read buffer is the first one, we're able to
> rewind without need for additional buffering.

... and if the current buffer isn't the first one, what do we do?

Show 22 quoted lines

> +#ifndef NO_CURL_IOCTL
> +curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)
> +{
> +	struct rpc_state *rpc = clientp;
> +
> +	switch (cmd) {
> +	case CURLIOCMD_NOP:
> +		return CURLIOE_OK;
> +
> +	case CURLIOCMD_RESTARTREAD:
> +		if (rpc->initial_buffer) {
> +			rpc->pos = 0;
> +			return CURLIOE_OK;
> +		}
> +		fprintf(stderr, "Unable to rewind rpc post data - try increasing http.postBuffer\n");
> +		return CURLIOE_FAILRESTART;
> +
> +	default:
> +		return CURLIOE_UNKNOWNCMD;
> +	}
> +}
> +#endif

What will this result in? A failed request, then the user increases http.postBuffer, and re-runs the entire command? I am not suggesting the code should do it differently (e.g. retry with a larger buffer without having the user to help it). At least not yet. That is why my first question above was "what do we do?" and not "what should we do?".

I am primarily interested in _documenting_ the expected user experience in the failure case, so that people can notice the message, run "git grep" to find the above line and then run "git blame" to find the commit to read its log message to understand what is going on.