- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 1 Aug 2019 19:46:26 +0300 (EEST)
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- CC: Matthew Kerwin <matthew@kerwin.net.au>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
> It's difficult for a server to guess at the client intent. Not sending > PRIORITY information is also a signal to prioritise the request with > default RFC7540 parameters (depend on root node with weight 16). So having > a clear signal from client to server along the lines of "I don't intend to > send, and don't infer any RFC7540 meaning from it" avoids that problem and > my impression from Montreal was that this is a desirable goal. In Montreal > we also discussed a possible experiment where the H2 PRIORITY frame > contents would be repurposed, which requires a compatible server to read it > correctly. In this case the signal would be more like "will send in an > RFC7540-incompatible format". > > Lucas Note that http client may send data before it is read SETTINGS frame which is part of the server connection preface. https://tools.ietf.org/html/rfc7540#section-3.5https://tools.ietf.org/html/rfc7540#section-3.5 | To avoid unnecessary latency, clients are permitted to send | additional frames to the server immediately after sending the client | connection preface, without waiting to receive the server connection | preface. It is important to note, however, that the server | connection preface SETTINGS frame might include parameters that | necessarily alter how a client is expected to communicate with the | server. Upon receiving the SETTINGS frame, the client is expected to | honor any parameters established. In some configurations, it is | possible for the server to transmit SETTINGS before the client sends | additional frames, providing an opportunity to avoid this issue. So if SETTINGS frame changes meaning of PRIORITY data which is already sent, that causes that server will interpreted it different than what http client intended. There may be also Stream Dependency field on HEADERS frame. And also PRIORITY frame may be send before HEADERS frame when stream is on idle state. So that repurpose will not work. / Kari Hurtta
Received on Thursday, 1 August 2019 16:47:04 UTC