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

On Fri, Sep 22, 2017 at 1:58 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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.

That is good.

>> 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?

For the client to use in response to cancelling a push?  Maybe we
needed one of those anyway.  This might not be the right time or place
to add that.  I could write a draft...

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

"contains zero or more instances of the Origin-Entry field." perhaps.

>> 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.
>
> Trying:
>
> 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
> question.

Good, except that PUSH_PROMISE never includes a response or even part thereof:

"...authoritative, both for responses to requests made by the client
and for server push (see {{!RFC7540}}, Section 8.2.2)."  Or something
like that.

Received on Friday, 22 September 2017 12:43:11 UTC