[PATCH v2] upload-pack: allow stateless client EOF just prior to haves
- From
Daniel Duvall <dan@mutual.io>
- Date
- Oct 30, 2020, 22:35 UTC
- Message-ID
- <20201030223504.45978-1-dan@mutual.io>
- In-Reply-To
- <1604022059-18527-1-git-send-email-dan@mutual.io>
During stateless packfile negotiation where a depth is given, stateless RPC clients (e.g. git-remote-curl) will send multiple upload-pack requests with the first containing only the wants/shallows/deepens/filters and the subsequent containing haves/done.
When upload-pack handles such requests, entering get_common_commits without first whether the client has hung up can result in unexpected EOF during the negotiation loop and a die() with message "fatal: the remote end hung up unexpectedly".
Real world effects include:
- A client speaking to git-http-backend via a server that doesn't check the exit codes of CGIs (e.g. mod_cgi) doesn't know and doesn't care about the fatal. It continues to process the response body as normal.
- A client speaking to a server that does check the exit code and returns an errant HTTP status as a result will fail with the message "error: RPC failed; HTTP 500 curl 22 The requested URL returned error: 500."
- Admins running servers that surface the failure must workaround it by patching code that handles execution of git-http-backend to ignore exit codes or take other heuristic approaches.
- Admins may have to deal with "hung up unexpectedly" log spam related to the failures even in cases where the exit code isn't surfaced as an HTTP server-side error status.
To avoid these EOF related fatals, have upload-pack gently peek for an EOF between the sending of shallow/unshallow lines (followed by flush) and the reading of client haves. If the client has hung up at this point, exit normally.
Signed-off-by: Daniel Duvall <dan@mutual.io>
---
Changes in v2: - Replaced unconditional flipping (XOR) of PACKET_READ_GENTLE_ON_EOF bit w/ `&= ~` to flip it back off (as it was when reader was initialized in previous clause) - Renamed test filename to group with other upload-pack related tests - Refactored test using packetize helper - Clarified in commit message that file descriptor is still valid but client hangup/EOF is the core issue - Added possible real-world effects of bug to commit message as suggested
--- t/t5705-upload-pack-stateless-shallow-eof.sh | 24 ++++++++++++++++++++ upload-pack.c | 13 ++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-) create mode 100755 t/t5705-upload-pack-stateless-shallow-eof.sh
diff --git a/t/t5705-upload-pack-stateless-shallow-eof.sh b/t/t5705-upload-pack-stateless-shallow-eof.sh new file mode 100755 index 0000000000..cc9d4baa0b --- /dev/null +++ b/t/t5705-upload-pack-stateless-shallow-eof.sh @@ -0,0 +1,24 @@ +#!/bin/sh + +test_description='stateless upload-pack gently handles EOF just after want/shallow/depth/flush' + +. ./test-lib.sh + +test_expect_success 'upload-pack outputs flush and exits ok' ' + test_commit initial && + head=$(git rev-parse HEAD) && + + { + packetize "want $head" && + packetize "shallow $head" && + packetize "deepen 1" && + printf "0000" + } >request && + + printf "0000" >expect && + git upload-pack --stateless-rpc . <request >actual && + + test_cmp expect actual +' + +test_done diff --git a/upload-pack.c b/upload-pack.c index 3b858eb457..5dc8e1f844 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -1344,7 +1344,18 @@ void upload_pack(struct upload_pack_options *options) PACKET_READ_DIE_ON_ERR_PACKET); receive_needs(&data, &reader); - if (data.want_obj.nr) { + + /* + * An EOF at this exact point in negotiation should be + * acceptable from stateless clients as they will consume the + * shallow list before doing subsequent rpc with haves/etc. + */ + if (data.stateless_rpc) + reader.options |= PACKET_READ_GENTLE_ON_EOF; + + if (data.want_obj.nr && + packet_reader_peek(&reader) != PACKET_READ_EOF) { + reader.options &= ~PACKET_READ_GENTLE_ON_EOF; get_common_commits(&data, &reader); create_pack_file(&data, NULL); }
-- 2.29.1.1.ge14d223