Subject: Re: constraining scheme (http vs https) on a connection

From: Erik Nygren <[email-masked]>
Date: Wed, 1 Jun 2016 11:18:47 -0400

If it helps, this came up as an important corner-case during implementation
/ detailed-design of a server-side implementation.

On Tue, May 31, 2016 at 10:06 PM, Martin Thomson <[email-masked]>
wrote:

> This is reasonable.  A boolean `mixed-scheme` member that has to be
> true seems appropriate.  It's cheap enough to warrant doing.
>
> On 1 June 2016 at 11:10, Mark Nottingham <[email-masked]> wrote:
> > What do other folks think?
> >
> >
> >> On 1 Jun 2016, at 8:31 AM, Erik Nygren <[email-masked]> wrote:
> >>
> >> Filed for the opp-sec draft where this is most relevant:
> >>
> >>      https://github.com/httpwg/http-extensions/issues/188
> >>
> >> In particular, mixing of secure and insecure schemes should require
> server-side opt-in over a strongly authenticated channel.  (eg, an
> attribute of /.well-known/http-opportunistic with properties similar to
> "commit" as for where it can be set).
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Jun 2016 10:06:13 +1000

Does Martin's suggestion of a flag in the .well-known file work for you?

Cheers,

> On 2 Jun 2016, at 1:18 AM, Erik Nygren <[email-masked]> wrote:
> 
> If it helps, this came up as an important corner-case during implementation / detailed-design of a server-side implementation.
> 
> 
> On Tue, May 31, 2016 at 10:06 PM, Martin Thomson <[email-masked]> wrote:
> >> In particular, mixing of secure and insecure schemes should require server-side opt-in over a strongly authenticated channel.  (eg, an attribute of /.well-known/http-opportunistic with properties similar to "commit" as for where it can be set).
> 
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Erik Nygren <[email-masked]>
Date: Wed, 1 Jun 2016 21:20:09 -0400

Yes, what Martin suggests makes total sense.

On Wed, Jun 1, 2016 at 8:06 PM, Mark Nottingham <[email-masked]> wrote:

> > If it helps, this came up as an important corner-case during
> implementation / detailed-design of a server-side implementation.
> >
> >