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

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.

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.

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.

Nits:

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

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

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

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.

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


On Wed, Sep 13, 2017 at 4:33 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> Gentlefolk of HTTPbis,
>
> The authors and myself (as chair) have decided that
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/ (-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
>

Received on Friday, 22 September 2017 01:13:14 UTC