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

Mark Andrews <marka@isc.org> Mon, 25 July 2011 04:36 UTC

Return-Path: <marka@isc.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DECE21F84ED; Sun, 24 Jul 2011 21:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level:
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVO99dEVd5Cb; Sun, 24 Jul 2011 21:36:44 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6192F21F84DC; Sun, 24 Jul 2011 21:36:44 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 886065F98FD; Mon, 25 Jul 2011 04:36:17 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 75176216C7B; Mon, 25 Jul 2011 04:35:45 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0A49C1222F02; Mon, 25 Jul 2011 14:35:43 +1000 (EST)
To: Keith Moore <moore@network-heretics.com>
From: Mark Andrews <marka@isc.org>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture> <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com> <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <B2C17B21-EA8A-4698-8C41-F55A9AA140D4@gbiv.com> <20110724073323.EEAAF121E985@drugs.dv.isc.org> <4B3C19FD-B736-4DA7-9DB5-3D433320DCBC@network-heretics.com> <20110725032136.A36701222CE2@drugs.dv.isc.org> <3BC48562-6459-4FB9-9806-731AF87FE027@network-heretics.com>
In-reply-to: Your message of "Sun, 24 Jul 2011 23:33:04 -0400." <3BC48562-6459-4FB9-9806-731AF87FE027@network-heretics.com>
Date: Mon, 25 Jul 2011 14:35:42 +1000
Message-Id: <20110725043543.0A49C1222F02@drugs.dv.isc.org>
X-Mailman-Approved-At: Sun, 24 Jul 2011 22:10:28 -0700
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 04:36:45 -0000

In message <3BC48562-6459-4FB9-9806-731AF87FE027@network-heretics.com>om>, 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"quot;.

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@isc.org