Currently, the document says this about redirection:
Commonly, servers will not want to actually operate the oblivious gateway on a well-known URI. In such cases, servers can use 3xx redirection responses to direct clients and relays to the correct location of the oblivious gateway.
Generally, the first request a client will make will be a GET request to discover the key configuration, described in Section 6. This initial request also provides a convenient way for clients to learn about the redirect from the well-known resource, if there is a redirect. When clients work with their oblivious relays to send oblivious requests to the gateway, clients can communicate this redirected gateway URI.
If a client follows a redirect for fetching the config, it MUST NOT communicate the redirected URL to the relay as the thing to send requests to, to avoid the redirect encoding something like the client IP address (or any unique value) in the URL and thus targeting clients. Instead, the client needs to only communicate the well-known version.
Based on discussion in https://mailarchive.ietf.org/arch/msg/ohai/zCtoK3dpapp4SrF87fDV3FIs-Io/
Currently, the document says this about redirection:
If a client follows a redirect for fetching the config, it MUST NOT communicate the redirected URL to the relay as the thing to send requests to, to avoid the redirect encoding something like the client IP address (or any unique value) in the URL and thus targeting clients. Instead, the client needs to only communicate the well-known version.