W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Secdir last call review of draft-ietf-httpbis-http2bis-06

From: Martin Thomson <mt@lowentropy.net>
Date: Tue, 07 Dec 2021 17:12:05 +1100
Message-Id: <2ba1e1fd-ce3b-4411-a155-6ee05537b935@www.fastmail.com>
To: "Sean Turner" <sean@sn3rd.com>, secdir@ietf.org
Cc: draft-ietf-httpbis-http2bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Hey Sean,

Most of your changes are pretty straightforward and easy to address.   Thanks for the review.

You can review the changes I'm proposing here: https://github.com/httpwg/http2-spec/pull/1001

On Tue, Dec 7, 2021, at 15:19, Sean Turner via Datatracker wrote:
> s3.3 (editorial): Even though s3 is clear that this section is about starting
> with http, I would have thought that the last sentence in para 2 would have
> been the very 1st sentence in the section to make that point very clear in case
> it missed in s3.

Yeah, this is a little buried.  At the same time, I do somewhat like the natural flow that this text has.  The pull request above tries to pull out the important piece, but I'm not sure that I made it better in the process.  We'll kick it around some.

> 5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disabled, but
> in s5.2.2 you explain how to do exactly that. In s5.2.1, are you really saying
> you can’t skip implementing the flow control mechanism and frames related to
> connection control, i.e., WINDOW_UPDATE?

Good question.  I've clarified by saying that endpoints have to respect flow control set by their peer, even though they can opt out of setting limits of their own.  The original was incorrect-ish, but I was never motivated to fix it before.

> s7 (question): Since we already have h3, is it worth adding an h3 required
> error?

I don't think we need it for various reasons, mostly because HTTP/1.1 is very much lowest common denominator, from which we can kick off Alt-Svc and other stuff.  We've discussed various options in this space and we continue to have those discussions, but I don't get the impression that the HTTP11_REQUIRED thing is anything more than safety valve.

> s8.3.1 (question): s8.3.1 includes this:
>
>      The recipient of a HTTP/2 request MUST ignore
>       the Host header field if :authority is present.
>
> And, it also includes this:
>
>      A server SHOULD treat a request as malformed if
>      it contains a Host header field that identifies a
>      different entity to the :authority pseudo-header field.
>
> If I follow the MUST, then is the SHOULD ever followed?

The MUST was not intended to be so broad; it's OK to validate as well.  What we don't want to see is the Host header field being used to determine the target URI.  I've narrowed it some (hopefully not too much).

> s11 (confirmation, and I guess this is somewhat related to the last GENART
> comment): Because you obsolete RFC 7540 with this I-D, I am going with the
> assumption that the obsoleting is about the protocol and not about the
> registries. As a result, there’s no need to copy the IANA instructions for
> what’s in 7540 to this I-D.

Yeah, I don't know that we're ever going to get this right, but I think that we can rely on what is in the registries already and save making another copy.  FWIW, IANA got the changes absolutely right first time, so I don't think this is going to produce a bad result.  It's just a bit odd, that's all.

> s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446?

I am not sure that I want to wait behind that.  As that particular change is easy, it's something we can do if the stars align at any time before AUTH48, so I've been putting off that decision in the hopes that we can go out together.  Of course, I was hoping that this could go out with HTTP/3 and all the other HTTP docs, but that opportunity seems to have passed.

Thanks,
Martin
Received on Tuesday, 7 December 2021 06:12:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 7 December 2021 06:12:40 UTC