Re: Using SRV records with a http Web Service

SRV records have come up on the list previously for HTTP/2 and it appears
the current official position is that SRV is not supported for HTTP:
https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html

As for the use of the Host header it is really the logical name of the
origin. There are two distinct concepts in play here. One is the URL
(including the authority which includes the Host) which logically describes
the resource we want to interact with. The other is this concept of which
host and port we connect to in order to reach that resource.

If a proxy is in play we connect to the proxy. If an origin server runs a
single site or service or that origin server runs multiple sites or
services we connect to that origin server. In all cases we want to preserve
the URL of the resource we want to interact with. The Host header either
carries the authority part of the URL or the request line contains the URL
and Host is included but can be left blank.

In your case it would be difficult to logically express the mmm service in
a URL. http://example.com:mmm/ is invalid as the port must be numeric. In
your case the logically consistent thing to do would be to make the SRV
service "http" and include the "real" service name (mmm in your example) as
part of the SRV host. I.e.
_http._tcp.mmm.example.com SRV 0 5 80 host1.example.com
Your URL authority and your Host header would be mmm.example.com,
preserving the service information in the request. However, as stated above
using SRV will likely lead to interoperability problems.

Benjamin.

On Fri, 18 Dec 2015 02:45 Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

> On Tue, Dec 15, 2015 at 2:31 PM, Patrick McManus <mcmanus@ducksong.com>
> wrote:
> > if you think of a srv as a more fine grained cname, the answer is
> obvious -
> > don't change the host header as it needs to reflect the origin.
>
> I had forgotten that CNAME is considered explicitly. that certainly
> excludes changing the host name to the SRV host address which was my
> main concern.
>
> Resolve ("example.com", "mmm")
>
> Get /.well-known/mmm/
> Host: example.com
>
> Still not happy throwing away information though.
>
>