W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

RE: non authenticated alternate services (was Re: AD review of draft-ietf-httpbis-alt-svc-10)

From: Mike Bishop <Michael.Bishop@microsoft.com>
Date: Sat, 16 Jan 2016 22:45:28 +0000
To: Patrick McManus <pmcmanus@mozilla.com>, Mark Nottingham <mnot@mnot.net>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Barry Leiba <barryleiba@computer.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, "draft-ietf-httpbis-alt-svc@ietf.org" <draft-ietf-httpbis-alt-svc@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, "hurtta-ietf@elmme-mailer.org" <hurtta-ietf@elmme-mailer.org>
Message-ID: <CY1PR03MB1374EBA4EFF5B80025C4F34D87CE0@CY1PR03MB1374.namprd03.prod.outlook.com>
I wasn’t even expecting it to have that much structure.  I’d be willing to buy that an ordinary user couldn’t cause /.well-known/alt-svc to exist in the first place; its existence (even if empty) is a signal that the admin knows about Alt-Svc and has done whatever is needful to keep unauthorized persons from setting it (like restricting that header from user-controlled content).  Just check for 2XX/4XX and be done.

From: Patrick McManus [mailto:pmcmanus@mozilla.com]
Sent: Saturday, January 16, 2016 12:05 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>; Mike Bishop <Michael.Bishop@microsoft.com>; Barry Leiba <barryleiba@computer.org>; Julian F. Reschke <julian.reschke@gmx.de>; draft-ietf-httpbis-alt-svc@ietf.org; HTTP Working Group <ietf-http-wg@w3.org>; hurtta-ietf@elmme-mailer.org
Subject: non authenticated alternate services (was Re: AD review of draft-ietf-httpbis-alt-svc-10)

Hi All, I apologize for letting this discussion go to my backlog. As Barry suggested, some of us need longer than others to shake off the new year's fog.
tl;dr; I've come to agree that an additional out of band check with an origin advertising an an-authenticated alt-service has value and we should modify the document to define that. It certainly has more value than either the port scheme or just allowing same host ports. Maybe something like the .well-known approach Kari suggests would be fine. Its certainly slow, but the whole thing migration is asynchronous anyhow so that's not a deal killer.
I'm actually glad the port number nonsense got called out. It didn't have real value and its the kind of window dressing only a committee could love (I say lovingly, as member of said committee.). Although moot now, I disagree that it was doing any harm by giving people a sense of self confidence - in general I think that kind of argument is too clever by half, people are generally paying no attention or less often paying enough attention to think it through.
I do have a concern that when reviewing the registry of .well-known https://www.iana.org/assignments/well-known-uris/well-known-uris.xml it isn't exactly overrun with well-used mechanisms. It seems to me .well-known is often offered up in the solutions space but not implemented as often.

I'm happy to help draft text if no one else wants to. Perhaps Mark, as author of rfc 5785, might want to suggest a structure. (do we need a separate document?) I think it can probably be a white list of advertisements on separate lines and also allowing *, but that's just an opening bid.

Received on Saturday, 16 January 2016 22:46:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC