Subject: draft-bishop-httpbis-extended-settings-00 comments

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 14:53:21 +1000

I am conflicted about this draft.  On the one hand, it's the design we
should have had for HTTP/2.  I like that it's more general, saves
space in most cases, and includes a flag to request acknowledgment.
All these are real improvements.

On the other hand, I don't think we need it now, and I'm not convinced
that will ever need it.  At some level, we can achieve the same effect
with careful use of SETTINGS and new frames.  For that reason, I'm
inclined to keep this on hold until we identify a few things that
depend on this.

-- on the details:

Section 2.  I think that SETTINGS_EXTENDED_SETTINGS is redundant.  You
can simply send the EXTENDED_SETTINGS frame to indicate that you
support it and have a reason to do so.  In most cases, the need to
support the frame will come with a need to send the frame, so it's a
pretty simple optimization.

What do you want to do about Http2-Settings?  Have we given up on the
pretense that there is a cleartext variant of HTTP/2?

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 13 Jul 2016 15:07:46 +1000

> pretense that there is a cleartext variant of HTTP/2?
​You mean Upgraded cleartext, yeah? Prior-knowledge cleartext doesn't
require Http2-Settings.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 15:16:19 +1000

On 13 July 2016 at 15:07, Matthew Kerwin <[email-masked]> wrote:
> You mean Upgraded cleartext, yeah? Prior-knowledge cleartext doesn't
> require Http2-Settings.

Right.  Of course, prior-knowledge is equally mythical, unless you
have a sighting you'd like to share.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 13 Jul 2016 15:27:06 +1000

> have a sighting you'd like to share.

I use it quite a bit on my closed networks, and I'm glad there's an
accommodating spec that ensures all the libraries and tools I use
interoperate.

Cheers

---

From: Cory Benfield <[email-masked]>
Date: Wed, 13 Jul 2016 09:42:51 +0100

> On 13 Jul 2016, at 06:27, Matthew Kerwin <[email-masked]> wrote:
> 

I also use it on closed networks, particularly as part of developing a H2 implementation. It’s extremely convenient that I have a small stable of tools that will send H2 with prior knowledge over a plaintext connection. I obviously don’t expect it to work over the *actual* internet, but where both tools are expecting it it works fine.

Cory

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Jul 2016 17:33:18 +0000

I mostly agree.  Certainly each extension could just define a XXX_SETTINGS frame that carries its own extension-local semantics.  There's no drawback to the extension itself to doing so -- describing a frame payload versus describing a setting payload is pretty equivalent spec work.  The question is whether it simplifies implementations to have a single instance of how to handle this frame, versus having to code handling for each XXX_SETTINGS frame as it gets defined, each with its local quirks.  However, that inclines me to the other direction -- this isn't substantially more difficult than adding a CERT_SETTINGS frame to the certs draft, and it might simplify something in the future, so why not?  I just worry that instances where this could have been used will crop up with just low enough frequency that there are never more than 1-2 outstanding at a time, but they'll exist.

You're correct that the setting to enable this could be replaced with a requirement to MUST send one of these, even if it's empty.  You need something to gate enabling the ACK timer on, but which of those two it is doesn't really matter.

As to the HTTP/1.1 header on upgrade, that's a good point and should probably be defined. The flip side of this versus legacy SETTINGS is that I could envision this growing pretty large in some instances -- it might make more sense to encode each setting as a header.  Details we can sort out if we go down this road.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2016 9:53 PM
To: HTTP Working Group <[email-masked]>
Subject: draft-bishop-httpbis-extended-settings-00 comments

I am conflicted about this draft.  On the one hand, it's the design we should have had for HTTP/2.  I like that it's more general, saves space in most cases, and includes a flag to request acknowledgment.
All these are real improvements.

On the other hand, I don't think we need it now, and I'm not convinced that will ever need it.  At some level, we can achieve the same effect with careful use of SETTINGS and new frames.  For that reason, I'm inclined to keep this on hold until we identify a few things that depend on this.

-- on the details:

Section 2.  I think that SETTINGS_EXTENDED_SETTINGS is redundant.  You can simply send the EXTENDED_SETTINGS frame to indicate that you support it and have a reason to do so.  In most cases, the need to support the frame will come with a need to send the frame, so it's a pretty simple optimization.

What do you want to do about Http2-Settings?  Have we given up on the pretense that there is a cleartext variant of HTTP/2?