Support client-redirection

[duijf]

When connecting to the secondary in a high availability setup, it is possible to get a 307 TEMPORARY REDIRECT response when Vault cannot forward a request to the primary on behalf of the client (docs).

We currently don't follow these redirects and might want to support this.

[HugoPeters1024]

I realize it might not be fresh in your mind anymore after over 5 years, but can you elaborate why you believe these redirects are not being followed. Judging from the request we build:

vaultenv/app/Main.hs

Lines 431 to 437 in 285463d

	setRequestManager (cHttpManager context)
	$ setRequestHeader "x-vault-request" ["true"]
	$ setRequestPath (SBS.pack path)
	$ setRequestPort (getOptionsValue oVaultPort cliOptions)
	$ setRequestHost (SBS.pack (getOptionsValue oVaultHost cliOptions))
	$ setRequestSecure (getOptionsValue oConnectTls cliOptions)
	$ defaultRequest

we use the defaultRequest which comes with a limit of 10 retries: https://hackage.haskell.org/package/http-client-0.7.13.1/docs/src/Network.HTTP.Client.Request.html#defaultRequest. From what I understand 307 is almost equivalent to 302 and I see no reason why if 302s are respected, 307s would not be.

[duijf]

I am not sure if/how vaultenv has changed since I created this issue. I might also have been mistaken regarding "We don't currently support these redirects"

With the setup we had at that time, I believe the Vault secondary could always perform the request forwarding on behalf of the client. (So we shouldn't have ever seen this redirect behaviour in practice). Not sure if anything changed here

You can try to test how vaultenv currently behaves by:

• Running a local vault setup in HA mode and setting and setting X-Vault-No-Request-Forwarding
• Mocking the 307 redirect in some other fashion.

You might find that vaultenv indeed needs to be modified to support this, or that there is nothing to do here 😄