In message <3BC48562-6459-4FB9-9806-731AF87FE027@xxxxxxxxxxxxxxxxxxxx>, Keith M oore writes: > On Jul 24, 2011, at 11:21 PM, Mark Andrews wrote: > > >>> How do you solve the problem of hosting just "http://example.com/"; > >>> on "s1.joes-web-service.com" and not redirect everything else at > >>> example.com? People have been complaining about this for about as > >>> long as the web has existed. > >>=20 > >> Well, in a way, that's what NAPTR was for. All of the UR > >> i resolution mechanisms (equally applicable to DNS-based URIs) that = > were =3D > >> developed and never really used grew out of the original realization = > in =3D > >> the early 1990s that CERN could stop hosting the original web pages = > if =3D > >> it wanted to, and there was no way to keep those links from going = > stale. > >=20 > > NAPTR is not defined for HTTP. > > SRV is not defined for HTTP. > >=20 > >> The problem never went away, but the DNS-based solutions were defined = > a =3D > >> long time ago and never used. > >=20 > > No. It was explitly NOT defined. > > Ok, fair enough. Those of us who were working on the DNS-based URI = > resolution mechanisms realized that they could be applied to http URIs = > in addition to almost anything else (NAPTR is incredibly flexible if you = > don't mind doing lots of DNS lookups). But they were never formally = > adopted. > > But if you really want to use DNS to do redirects for http: URIs (or for = > that matter ws: URIs or almost any other kind of URI), NAPTR was = > tailor-made to do that. SRV was not. "_http._tcp.example.com SRV 100 0 80 <server>" is not a redirect. The http client still issues "Host: example.com" not "Host: <server>". If you want to do DNS level redirect of "www.example.com" to "example.com" then NAPTR would be the way to do that and the http client issues "Host: example.com" instead of "Host: www.example.com". If web browers were using CNAME records correctly, i.e. as aliases, then they would be treated as a DNS level redirect not as "return the address of CNAME target but otherwise ignore that this is a alias". Doing this has all sorts if implications. A lot of the IDN issues are a direct result of HTTP clients/adminstrators abusing CNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf