Subject: Call for Adoption: draft-nottingham-httpbis-origin-frame

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Mar 2016 10:58:06 +1100

<https://tools.ietf.org/html/draft-nottingham-httpbis-origin-frame-01>

As we've seen, there's some implementer interest in this, and in previous discussions, there seem to have been support for it. Our AD is aware of it and supportive of its adoption.

If you'd like to express support for it or reservations about adopting it, please do so; we'll make a decision shortly.

Since I'm an author on the document, Mike Bishop has graciously agreed to act as Document Shepherd and judge consensus for it.

Regards,

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 15 Mar 2016 20:16:11 -0400

as noted, I'm in favor and interested in where this can go.

On Tue, Mar 15, 2016 at 7:58 PM, Mark Nottingham <[email-masked]> wrote:

> As we've seen, there's some implementer interest in this, and in previous
> discussions, there seem to have been support for it. Our AD is aware of it
> and supportive of its adoption.
>
> If you'd like to express support for it or reservations about adopting it,
> please do so; we'll make a decision shortly.
>
> Since I'm an author on the document, Mike Bishop has graciously agreed to
> act as Document Shepherd and judge consensus for it.
>
> Regards,
>
>
>
>
> --

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 16 Mar 2016 10:04:26 +0100

Interested to support this in Apache httpd.

The handling of 421 responses is not the same for all clients. This has caused some problems in deployment where not all sites listed in a cert enjoy the same TLS configuration. With renegotiation not possible, a server can only 421 such a request.

My hope for an ORIGIN frame is that the server can indicate which hosts *really* are mixable on the connection and clients can refrain from second guessing from alternate names only.

-Stefan

> Am 16.03.2016 um 01:16 schrieb Patrick McManus <[email-masked]>:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Mar 2016 20:08:29 +1100

Hi Stefan,

> On 16 Mar 2016, at 8:04 PM, Stefan Eissing <[email-masked]> wrote:
> 

Can you expand upon this a bit? What differences are you seeing?

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 16 Mar 2016 10:19:51 +0100

> Am 16.03.2016 um 10:08 schrieb Mark Nottingham <[email-masked]>:
> 
> Hi Stefan,
> 

I got several users who reported that Chrome did not open a new connection under certain circumstances and failed the request. Since they needed the setup as it was, they could only disable h2 for the time being. That was in 2.4.17 when httpd would answer almost all differences between SNI and :authority with a 421. Which was, admittedly, a bit harsh. And the fine folks from Chrome probably have improved that part already. I did not have the time to check in detail.

With 2.4.18, 421 is only used when TLS configurations are not compatible, e.g. not using the same ciphers/protocol version etc. So, people do configure around it, when needed and possible.

But when clients encounter a 421, not all have exposed the same handling, nor probably ever will. Was the 421 request a POST? How much body had already been sent? etc..

That is where I hope a ORIGIN frame could make things more predictable.

-Stefan

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Mar 2016 12:09:33 +1100

> But when clients encounter a 421, not all have exposed the same handling, nor probably ever will. Was the 421 request a POST? How much body had already been sent? etc..

The hope was that the definition was clear: this request is safe to
retry.  But nothing forces anyone to do anything I guess, even if that
might be the right thing.