I think only sending it on the control stream is fine, as you can bundle a STREAM frame from the control frame with that of the request stream into a single datagram. I don't think I'd object to sending it on the request stream, but the only clear benefit is saving a few bytes. And of course, Chrome may change to use the header for the initial priority at some point after evaluation, but for now this approach is a bit simpler. On Thu, Mar 5, 2020 at 3:05 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > > > On Thu, Mar 5, 2020 at 7:51 PM Ian Swett <ianswett@google.com> wrote: > >> The draft is written with that in mind, but there's no requirement in >> design or the draft that an implementation can only use the header for >> initial prioritization. Chrome uses the frame for initial priority and >> updates and it seems to work fine. Obviously only the frame can be used >> for reprioritization. I expect Google HTTP/3 servers will end up >> supporting both. >> >> But I think the draft should be updated to describe the frame as HBH and >> able to be used for either initial or priority updates. >> >> In practice, due to reordering, implementations need to handle receiving >> the frame prior to the request anyway. >> >> I hope that clarifies my thinking, Ian >> > > Based on your implementation experience, would you be happy with the frame > being restricted to only being sent on the control stream? Or do you see > some need for allowing that frame on the request stream (noting that doing > so adds challenges to making it work with HTTP/2)? > > >Received on Thursday, 5 March 2020 20:10:05 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 5 March 2020 20:10:06 UTC