- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 22 Sep 2017 22:42:48 +1000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>, Erik Nygren <erik@nygren.org>
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