Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
oceantume opened this issue May 27, 2024 · 0 comments
Open

Comments

@oceantume
Copy link

oceantume commented May 27, 2024

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant