ietf
[Top] [All Lists]

Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

2011-07-24 23:37:39

In message 
<3BC48562-6459-4FB9-9806-731AF87FE027(_at_)network-heretics(_dot_)com>, 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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>