this is really the kind of thing quic should figure out how to put in transport parameters; I don't think we want to encourage waiting before sending origin info. It's definitely a bw for latency trade tho. On Thu, Sep 28, 2017 at 7:26 AM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote: > Right now the server has no way of knowing whether the client supports > ORIGIN or not. Would a client-sent ORIGIN_SUPPORT frame be a good way for > servers to decide whether or not to send ORIGIN frames (which could be > wasteful if the client doesn't support them)? Or are there downsides to > such a mechanism that I'm forgetting? > > Nick > > On Thu, Sep 28, 2017 at 3:28 AM Mark Nottingham <mnot@mnot.net> wrote: > >> I'm OK either way here; it's attractive to have a deadline for knowing >> whether the connection is under the ORIGIN model (first SETTINGS), but I'm >> also a bit nervous about introducing such a big change relatively late in >> the day. >> >> Put another way - does anyone think that this is clearly better than the >> current spec and needs to get in? >> >> PR here (still needs some work if we want to adopt): >> https://github.com/httpwg/http-extensions/pull/406 >> >> >> > On 28 Sep 2017, at 11:48 am, Martin Thomson <martin.thomson@gmail.com> >> wrote: >> > >> > On Thu, Sep 28, 2017 at 11:43 AM, Patrick McManus <pmcmanus@mozilla.com> >> wrote: >> >> I'm not going to object to the setting - it just seems it doesn't >> really >> >> address the fact that the client is going to see both 7540 rules and >> ORIGIN >> >> rules at some point on the same connection so there's not a lot of >> point to >> >> it imo. >> > >> > I see your point. It narrows, but doesn't eliminate the window of >> > uncertainty and as a result it isn't that much use to you. >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> >>
Received on Thursday, 28 September 2017 15:00:39 UTC