You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: