[prpc] Allow "peeking" into requests in the override callback.

The override callback is primarily used to implement traffic
splitting. It is called before an RPC handler and it may decide
to fully execute the request itself (usually by proxying it
to another service).

In Swarming we'll need to look at the pagination cursors to
decide if a listing request should be sent to Python or be
processed in Go. Thus the override callback needs a way to
"peek" into requests.

One complication is that http.Request.Body can be read at most
once. If we read it, and then decided to resume request
execution normally, we need to make sure it can be read again.
The only way to do that is to buffer the request in memory.
This should be fine, since most RPC requests are tiny (and
this is "temporary" code anyway).

For the same reason, the "peeking" is not optimal: if we resume
the processing of the request after "peeking", the request will
be deserialized again (while in theory we could cache the peeked
value and reuse it). But this will complicate the code even more,
and, as mentioned, requests are tiny and this is temporary.

R=chanli@chromium.org

Change-Id: I03d4691db78b39bd1e2fe5a37ef279d2e2226675
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5599264
Reviewed-by: Chan Li <chanli@chromium.org>
Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
4 files changed
tree: f7d76485847899fdbacbd92c8a83d5a771725ae6
  1. analysis/
  2. appengine/
  3. auth/
  4. auth_service/
  5. bisection/
  6. build/
  7. buildbucket/
  8. casviewer/
  9. cipd/
  10. cipkg/
  11. client/
  12. common/
  13. config/
  14. config_service/
  15. cv/
  16. deploy/
  17. examples/
  18. gae/
  19. gce/
  20. grpc/
  21. hardcoded/
  22. led/
  23. logdog/
  24. luci_notify/
  25. lucicfg/
  26. lucictx/
  27. luciexe/
  28. mailer/
  29. milo/
  30. mmutex/
  31. provenance/
  32. resultdb/
  33. scheduler/
  34. scripts/
  35. server/
  36. standalone/
  37. starlark/
  38. swarming/
  39. teams/
  40. third_party/
  41. tokenserver/
  42. tools/
  43. tree_status/
  44. vpython/
  45. web/
  46. .gitallowed
  47. .gitattributes
  48. .gitignore
  49. .go-lintable
  50. AUTHORS
  51. codereview.settings
  52. CONTRIBUTING.md
  53. CONTRIBUTORS
  54. go.mod
  55. go.sum
  56. LICENSE
  57. OWNERS
  58. PRESUBMIT.py
  59. README.md
  60. tools.go
  61. WATCHLISTS
README.md

luci-go: LUCI services and tools in Go

GoReference

Installing

LUCI Go code is meant to be worked on from an Chromium infra.git checkout, which enforces packages versions and Go toolchain version. First get fetch via depot_tools.git then run:

fetch infra
cd infra/go
eval `./env.py`
cd src/go.chromium.org/luci

It is now possible to directly install tools with go install:

go install go.chromium.org/luci/auth/client/cmd/...@latest
go install go.chromium.org/luci/buildbucket/cmd/...@latest
go install go.chromium.org/luci/cipd/client/cmd/...@latest
go install go.chromium.org/luci/client/cmd/...@latest
go install go.chromium.org/luci/cv/cmd/...@latest
go install go.chromium.org/luci/gce/cmd/...@latest
go install go.chromium.org/luci/grpc/cmd/...@latest
go install go.chromium.org/luci/logdog/client/cmd/...@latest
go install go.chromium.org/luci/luci_notify/cmd/...@latest
go install go.chromium.org/luci/lucicfg/cmd/...@latest
go install go.chromium.org/luci/luciexe/legacy/cmd/...@latest
go install go.chromium.org/luci/mailer/cmd/...@latest
go install go.chromium.org/luci/mmutex/cmd/...@latest
go install go.chromium.org/luci/resultdb/cmd/...@latest
go install go.chromium.org/luci/server/cmd/...@latest
go install go.chromium.org/luci/swarming/cmd/...@latest
go install go.chromium.org/luci/tokenserver/cmd/...@latest
go install go.chromium.org/luci/tools/cmd/...@latest

Contributing

Contributing uses the same flow as Chromium contributions.