litefs icon indicating copy to clipboard operation
litefs copied to clipboard

Add the option to act as a real proxy instead of using fly-replay header

Open oceantume opened this issue 1 month ago • 0 comments

The fly-replay header is really cool but it comes with the limitation of being unable to handle requests larger than 1 MB. While there are listed workarounds, I feel like it could be interesting to allow basically proxying the request as-is to the primary directly (essentially implementing the proxy in go).

To be clear, I would not make this the default behavior. I'm thinking it could be put it behind an opt-in config key similarly to how passthrough paths are defined. It should be explicit, since this uses more resources (your request is going through two machines) and it will incur egress cost if you're transferring across regions.

Are you open to receiving pull requests for that kind of change? If so, would you change anything about what I described here?

Possible issues

  • If the request takes a while to transfer and the primary stops being the primary during that time, then any attempted write after the transfer will fail. That's not an issue specific to this suggestion though, since that kind of race condition is already possible (although less likely) with the current implementation.
  • I'm not sure how trivial it is to proxy a full http request in go. In theory you can just proxy to the remote server instead of the local application, but there may be more to it.

oceantume avatar May 27 '24 18:05 oceantume