spec that we follow redirects

proposals/1708-well-known-for-federation.md

@@ -35,14 +35,12 @@ is as follows:
 4. Finally, the server is discovered by looking up an AAAA or A record on the
    hostname, and taking the default fallback port number of 8448.
 
-We insert the following between Steps 3 and 4:
+We insert the following between Steps 3 and 4.
 
 If the SRV record does not exist, the requesting server should make a `GET`
-request to `https://<server_name>/.well-known/matrix/server`, with normal
-X.509 certificate validation. If the request does not return a 200, continue
-to step 4, otherwise:
-
-XXX: should we follow redirects?
+request to `https://<server_name>/.well-known/matrix/server`, with normal X.509
+certificate validation, and following 30x redirects. If the request does not
+return a 200, continue to step 4, otherwise:
 
 The response must have a `Content-Type` of `application/json`, and must be
 valid JSON which follows the structure documented below. Otherwise, the
@@ -114,14 +112,6 @@ must be taken that a single 500 error or connection failure should not break
 federation for an extended period. A short cache time of about an hour might be
 appropriate; alternatively, servers might use an exponential backoff.
 
-### Outstanding questions
-
-Should we follow 30x redirects for the .well-known file? On the one hand, there
-is no obvious usecase and they add complexity (for example: how do they
-interact with caches?). On the other hand, we'll presumably be using an HTTP
-client library to handle some of the caching stuff, and they might be useful
-for something?
-
 ## Problems
 
 It will take a while for `.well-known` to be supported across the ecosystem;