Martin Storsjö <martin@xxxxxxxxx> 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?
> +#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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html