Clarifications and alter the error handling of .well-known

Note that MSC1831 changes the order, so the changes to MSC1708 might not make sense when combining all the proposals together. However, independently the change should make sense.

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

@@ -44,8 +44,8 @@ redirect loops). If the request does not return a 200, continue to step 4,
 otherwise:
 
 The response must be valid JSON which follows the structure documented
-below. Otherwise, the request is aborted. It is NOT necessary for the response
+below. Otherwise, continue to the next step in the discovery process. It is
-to have a `Content-Type` of `application/json`.
+NOT necessary for the response to have a `Content-Type` of `application/json`.
 
 If the response is valid, the `m.server` property is parsed as
 `<delegated_server_name>[:<delegated_port>]`, and processed as follows:

specification/server_server_api.rst

@@ -109,14 +109,14 @@ The process overall is as follows:
 1. If the hostname is an IP literal, then that IP address should be used,
    together with the given port number, or 8448 if no port is given. The
    target server must present a valid certificate for the IP address.
-   Requests must be made with a ``Host`` header containing the IP address,
+   The ``Host`` header in the request should be set to the server name,
-   without port.
+   including the port if the server name included one.
 
-2. If the hostname is not an IP literal, and the server name includes an explicit port,
+2. If the hostname is not an IP literal, and the server name includes an
-   resolve the IP address using AAAA or A records. Requests are made to
+   explicit port, resolve the IP address using AAAA or A records. Requests
-   the resolved IP address and given port with a ``Host`` header of the
+   are made to the resolved IP address and given port with a ``Host`` header
-   original hostname (with port). The target server must present a valid
+   of the original server name (with port). The target server must present a
-   certificate for the hostname.
+   valid certificate for the hostname.
 
 3. If the hostname is not an IP literal, a regular HTTPS request is made
    to ``https://<hostname>/.well-known/matrix/server``, expecting the
@@ -130,39 +130,38 @@ The process overall is as follows:
    recommended. Errors are recommended to be cached for up to an hour,
    and servers are encouraged to exponentially back off for repeated
    failures. The schema of the ``/.well-known`` request is later in this
-   section. If the response is invalid (bad JSON, missing properties, etc),
+   section. If the response is invalid (bad JSON, missing properties, non-200
-   attempts to connect to the target server are aborted - no connections
+   response, etc), skip to step 4. If the response is valid, the ``m.server``
-   should be attempted. If the response is valid, the ``m.server`` property
+   property is parsed as ``<delegated_hostname>[:<delegated_port>]`` and
-   is parsed as ``<delegated_server_name>[:<delegated_port>]`` and processed
+   processed as follows:
-   as follows:
 
-   * If ``<delegated_server_name>`` is an IP literal, then that IP address
+   * If ``<delegated_hostname>`` is an IP literal, then that IP address
      should be used together with the ``<delegated_port>`` or 8448 if no
      port is provided. The target server must present a valid TLS certificate
      for the IP address. Requests must be made with a ``Host`` header containing
-     the IP address, with port.
+     the IP address, including the port if one was provided.
 
-   * If ``<delegated_server_name>`` is not an IP literal, and ``<delegated_port>``
+   * If ``<delegated_hostname>`` is not an IP literal, and ``<delegated_port>``
      is present, an IP address is disovered by looking up an AAAA or A
-     record for ``<delegated_server_name>``. The resulting IP address is
+     record for ``<delegated_hostname>``. The resulting IP address is
-     used, alongside the ``<delegated_port>``, to make requests with a
+     used, alongside the ``<delegated_port>``. Requests must be made with a
-     ``Host`` header of ``<delegated_server_name>:<delegated_port>``. The
+     ``Host`` header of ``<delegated_hostname>:<delegated_port>``. The
-     target server must present a valid certificate for ``<delegated_server_name>``.
+     target server must present a valid certificate for ``<delegated_hostname>``.
 
-   * If ``<delegated_server_name>`` is not an IP literal and no
+   * If ``<delegated_hostname>`` is not an IP literal and no
      ``<delegated_port>`` is present, an SRV record is looked up for
-     ``_matrix._tcp.<delegated_server_name>``. This may result in another
+     ``_matrix._tcp.<delegated_hostname>``. This may result in another
      hostname (to be resolved using AAAA or A records) and port. Requests
      should be made to the resolved IP address and port with a ``Host``
-     header containing the ``<delegated_server_name>``. The target server
+     header containing the ``<delegated_hostname>``. The target server
-     must present a valid certificate for ``<delegated_server_name>``.
+     must present a valid certificate for ``<delegated_hostname>``.
 
    * If no SRV record is found, an IP address is resolved using AAAA
      or A records. Requests are then made to the resolve IP address
-     and a port of 8448, using a ``Host`` header of ``<delegated_server_name>``.
+     and a port of 8448, using a ``Host`` header of ``<delegated_hostname>``.
-     The target server must present a valid certificate for ``<delegated_server_name>``.
+     The target server must present a valid certificate for ``<delegated_hostname>``.
 
-4. If the `/.well-known` request did not result in a 200 response, a server
+4. If the `/.well-known` request resulted in an error response, a server
    is found by resolving an SRV record for ``_matrix._tcp.<hostname>``. This
    may result in a hostname (to be resolved using AAAA or A records) and
    port. Requests are made to the resolved IP address and port, using 8448