Re: Working Group Last Call The ORIGIN HTTP/2 Frame

> On 22 Sep 2017, at 11:12 am, Martin Thomson <> wrote:
> I've read this again.
> This is basically done.  I have some pretty minor comments, and some
> editorial nits, some of which will appear as a PR shortly.
> Minor things:
> Section 1.  I think that the last paragraph needs another sentence to
> capture the general gist of the recent changes.  Rather than flat out
> removing the requirement to check DNS, the document describes the
> conditions under which that requirement is removed, and some advice on
> when that might be appropriate.

Something like:

This specification relaxes the requirement to check DNS when the ORIGIN frame is in use, provided that other assurances about the server's authority are obtained.


> Section 2.2.  The text on flags and forward/backward compatibility offers no clue about how contention over these bits is managed.  I would suggest a IETF consensus RFC is the only thing that can define new flags, but that's just the third thing I thought of.

That's the intent of "future updates to this specification" -- will spell it out.

> Section 4.
>   The Origin Set's size is unbounded by this specification, and thus
>   could be used by attackers to exhaust client resources.  To mitigate
>   this risk, clients can monitor their state commitment and close the
>   connection if it is too high.
> A client could also start forgetting origins that it hasn't used.
> There is no demonstrable harm in that and an LRU is less disruptive to
> all involved.

What do people think here? Is a LRU going to cause problems with the server having even less information about what the client considers the connection authoritative for?

Also, should we identify an error code to use in this situation?

> Nits:
> Section 2.1.  The sentence ending "contains zero to many
> Origin-Entry." reads poorly.  Maybe some extra words will fix this.

Suggest some?

> Section 2.3.  In the note "the initial origin set Section 2.3"
> probably needs parentheses around the reference.

Your pull took care of this, thanks.

> Section 2.4.  s/[RFC7540] Section 9.1.1/[RFC7540], Section 9.1.1/ -
> twice: note comma; and the same for the 5280 reference

I believe your pull took care of this too. Well, almost all of it.

> Section 2.4.
>   Furthermore, [RFC7540] Section 9.1.1 explicitly allows a connection
>   to be used for more than one origin server, if it is authoritative.
>   This affects what requests can be sent on the connection, both in
>   HEADERS frame by the client and as PUSH_PROMISE frames from the
>   server ([RFC7540], Section 8.2.2).
> This isn't really perfectly accurate.  It's not awful, but the last
> sentence implies that the request is what is important, but I think
> that we should concentrate more on the response.  That is, authority
> determines the identity of the origin server (or servers) for which
> the client will accept responses.  This limits what origins it should
> send requests for, and what origins it should accept server pushes
> from.


This affects what responses can be considered
authoritative, both in HEADERS and PUSH_PROMISE frames from the server ({{!RFC7540}}, Section
8.2.2). Indirectly, it also affects what requests will be sent on a connection, since clients will
generally only send requests on connections that they believe to be authoritative for the origin in

> Note to chairs: you may need to find another shepherd for this document.


> On Wed, Sep 13, 2017 at 4:33 AM, Patrick McManus <> wrote:
>> Gentlefolk of HTTPbis,
>> The authors and myself (as chair) have decided that
>> (-04) is
>> ready for the working group last call. Please review it and raise any issues
>> on the list over the next two weeks. The most recent changes are focused in
>> the security considerations. There are currently no open issues in the
>> github tracker.
>> WGLC will end on October 01, 2017.
>> Thanks
>> -Patrick

Mark Nottingham

Received on Friday, 22 September 2017 03:58:30 UTC