In message
<4B3C19FD-B736-4DA7-9DB5-3D433320DCBC(_at_)network-heretics(_dot_)com>, Keith M
oore writes:
On Jul 24, 2011, at 3:33 AM, 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.
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 =
developed and never really used grew out of the original realization in =
the early 1990s that CERN could stop hosting the original web pages if =
it wanted to, and there was no way to keep those links from going stale.
NAPTR is not defined for HTTP.
SRV is not defined for HTTP.
The problem never went away, but the DNS-based solutions were defined a =
long time ago and never used.
No. It was explitly NOT defined.
RFC 2782
Applicability Statement
In general, it is expected that SRV records will be used by clients
for applications where the relevant protocol specification indicates
that clients should use the SRV record. Such specification MUST
define the symbolic name to be used in the Service field of the SRV
record as described below. It also MUST include security
considerations. Service SRV records SHOULD NOT be used in the absence
of such specification.
By now, I think the market has long =
since decided. For better or worse, the mechanism the market chose to =
use with the web was HTTP redirects.
If the market hasn't has a really opportunity do decide as only one
mechanism has been specified and coded. Most people don't know of
the existence of SRV or that it would be useful for HTTP.
If the only tool you have is a hammer then you use a hammer even
if a screwdriver would be better.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf