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

Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 29, 2009, 03:42 UTC
Message-ID
<7vd446dfx4.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1256774448-7625-15-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 10 quoted lines
> When --stateless-rpc is passed as a command line parameter to
> upload-pack or receive-pack the programs now assume they may
> perform only a single read-write cycle with stdin and stdout.
> This fits with the HTTP POST request processing model where a
> program may read the request, write a response, and must exit.
>
> When --advertise-refs is passed as a command line parameter only
> the initial ref advertisement is output, and the program exits
> immediately.  This fits with the HTTP GET request model, where
> no request content is received but a response must be produced.

Is the idea to first run with --advertise-refs to get the set of refs, and then doing another, separate run with --stateless-rpc, assuming that the refs the other end advertised does not change in the meantime, to conclude the business?

I suspect that two separate invocations on a (supposedly) single repository made back-to-back can produce an inconsistent response in verious situations (e.g. somebody pushing in the middle, or the same hostname served by more than one mirrors) and the other end can get confused.

I do not think there is any way to avoid it, short of adding to the second request some "cookie" that allows the second requestee to verify that the request is based on what he would give to the requester if this request were the first step of the request made to him, iow, his state did not change in the middle since the first request was made (either to him or to the equivalent mirror sitting next to himm).

I wouldn't worry too much about this if the only negative effect could be that the requestor's second request may result in an error, but I am wondering if this can be used to attack the requestee.

Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 34 of 60 in “Return of smart HTTP”
  1. 00/26 Return of smart HTTPShawn O. Pearce, Oct 29, 2009
  2. 01/26 http-push: fix check condition on http.c::finish_http_pack_request()Shawn O. Pearce, Oct 29, 2009
  3. 02/26 pkt-line: Add strbuf based functionsShawn O. Pearce, Oct 29, 2009
  4. 03/26 pkt-line: Make packet_read_line easier to debugShawn O. Pearce, Oct 29, 2009
  5. Junio C HamanoOct 29, 2009
  6. Shawn O. PearceOct 29, 2009
  7. Junio C HamanoOct 29, 2009
  8. Shawn O. PearceOct 29, 2009
  9. Jeff KingOct 30, 2009
  10. Shawn O. PearceOct 30, 2009
  11. Jeff KingOct 30, 2009
  12. David BrownOct 30, 2009
  13. Junio C HamanoOct 30, 2009
  14. 04/26 fetch-pack: Use a strbuf to compose the want listShawn O. Pearce, Oct 29, 2009
  15. 05/26 Move "get_ack()" back to fetch-packShawn O. Pearce, Oct 29, 2009
  16. Junio C HamanoOct 29, 2009
  17. Shawn O. PearceOct 29, 2009
  18. 06/26 Add multi_ack_detailed capability to fetch-pack/upload-packShawn O. Pearce, Oct 29, 2009
  19. Junio C HamanoOct 29, 2009
  20. Shawn O. PearceOct 29, 2009
  21. 07/26 remote-curl: Refactor walker initializationShawn O. Pearce, Oct 29, 2009
  22. 08/26 fetch: Allow transport -v -v -v to set verbosity to 3Shawn O. Pearce, Oct 29, 2009
  23. 09/26 remote-helpers: Fetch more than one ref in a batchShawn O. Pearce, Oct 29, 2009
  24. 10/26 remote-helpers: Support custom transport optionsShawn O. Pearce, Oct 29, 2009
  25. 11/26 Move WebDAV HTTP push under remote-curlShawn O. Pearce, Oct 29, 2009
  26. Tay Ray ChuanOct 30, 2009
  27. Shawn O. PearceOct 31, 2009
  28. Tay Ray ChuanOct 30, 2009
  29. Clemens BuchacherOct 30, 2009
  30. Tay Ray ChuanOct 30, 2009
  31. 12/26 remote-helpers: return successfully if everything up-to-dateShawn O. Pearce, Oct 29, 2009
  32. 13/26 Git-aware CGI to provide dumb HTTP transportShawn O. Pearce, Oct 29, 2009
  33. 14/26 Add stateless RPC options to upload-pack, receive-packShawn O. Pearce, Oct 29, 2009
  34. Junio C HamanoOct 29, 2009
  35. Shawn O. PearceOct 29, 2009
  36. Junio C HamanoOct 29, 2009
  37. Shawn O. PearceOct 30, 2009
  38. 15/26 Smart fetch and push over HTTP: server sideShawn O. Pearce, Oct 29, 2009
  39. 16/26 http-backend: add GIT_PROJECT_ROOT environment varShawn O. Pearce, Oct 29, 2009
  40. 17/26 http-backend: reword some documentationShawn O. Pearce, Oct 29, 2009
  41. 18/26 http-backend: use mod_alias instead of mod_rewriteShawn O. Pearce, Oct 29, 2009
  42. 19/26 http-backend: add example for gitweb on same URLShawn O. Pearce, Oct 29, 2009
  43. 20/26 http-backend: more explict LocationMatchShawn O. Pearce, Oct 29, 2009
  44. 21/26 Discover refs via smart HTTP server when availableShawn O. Pearce, Oct 29, 2009
  45. 22/26 Smart push over HTTP: client sideShawn O. Pearce, Oct 29, 2009
  46. 23/26 Smart fetch over HTTP: client sideShawn O. Pearce, Oct 29, 2009
  47. 24/26 Smart HTTP fetch: gzip requestsShawn O. Pearce, Oct 29, 2009
  48. 25/26 t5540-http-push: remove redundant fetchesShawn O. Pearce, Oct 29, 2009
  49. 26/26 test smart http fetch and pushShawn O. Pearce, Oct 29, 2009
  50. Clemens BuchacherOct 29, 2009
  51. Shawn O. PearceOct 29, 2009
  52. Junio C HamanoOct 29, 2009
  53. Shawn O. PearceOct 29, 2009
  54. Shawn O. PearceOct 29, 2009
  55. Junio C HamanoOct 30, 2009
  56. Shawn O. PearceOct 30, 2009
  57. Tay Ray ChuanOct 30, 2009
  58. Shawn O. PearceOct 31, 2009
  59. Jakub NarebskiOct 29, 2009
  60. Shawn O. PearceOct 29, 2009

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.