- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 13 Aug 2019 20:48:39 +0100
- To: Mike Bishop <mbishop@evequefou.be>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
- Message-ID: <CALGR9oY8ymGqJDKFsWjkqf2qXVhvkNHo8WUo17F5S-7_CZFNOQ@mail.gmail.com>
Hi Mike, On Tue, 13 Aug 2019, 19:48 Mike Bishop, <mbishop@evequefou.be> wrote: > This form of negotiation appears to presuppose sending multiple SETTINGS > frames. First you advertise that something is available, and only if it's > available on the other side do you then declare that you're sending it. > > > > HTTP/3 only permits a single SETTINGS frame in each direction, and for > latency reasons you really shouldn't wait to see the peer's values before > sending your own. Therefore, I think you wind up in one of three postures > for negotiating something like this: > > - Each side declares their supported schemes. There is a defined > algorithm by which each side, having both declarations, can conclude the > most mutually-preferred scheme. Clients can’t generate PRIORITY frames > until they’ve seen the server’s declaration. > - The server declares its supported schemes, each of which will use > different frame types. The client SHOULD NOT send more than one scheme > simultaneously (but perhaps MAY send all of them until it sees the SETTINGS > frame). > - Define a separate extension which is used for negotiation separate > from SETTINGS. > > > I agree. If I were to enumerate your points, then for point 1 Brad has some WIP text that makes our initial proposal more robust in this sense. And for point 3 I have a strawman not-yet-shared negotiation mechanism that uses extension frames in the manner you describe. Though seeing it written down I'm not convinced it doesn't generate another set of complication. Lucas > -----Original Message----- > From: Kari Hurtta <hurtta-ietf@elmme-mailer.org> > Sent: Saturday, August 3, 2019 3:58 AM > To: Lucas Pardue <lucaspardue.24.7@gmail.com>; HTTP Working Group < > ietf-http-wg@w3.org> > Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP Working Group < > ietf-http-wg@w3.org>; Matthew Kerwin <matthew@kerwin.net.au>; Brad Lassey > <lassey@chromium.org>; Dmitri Tikhonov <dtikhonov@litespeedtech.com> > Subject: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | > Re: Setting to disable HTTP/2 Priorities > > > > > Any client that is taking the chance to make a semantic change to the > > > frames it is sending would be foolish to not wait on an affirmative > > > signal from the server. RFC 7540 Section 5.5. calls specific attention > > > to such a > > > repurposing: > > > > > > > Extensions that could change the semantics of existing protocol > > > components MUST be negotiated before being used. For example, an > > > extension that changes the layout of the HEADERS frame cannot be used > > > until the peer has given a positive signal that this is acceptable. > > > > > > Lucas > > > > Okei, > > > > Generally repurpose of protocol element requires 3 values (or 2 bits from > bitmask) for SETTINGS parameter SETTINGS_ENABLE_{feature}. > > For example values > > > > • 0 {feature}_NOT_SUPPORTED, > > • 1 {feature}_AVAILABLE > > • 3 SENDING_{feature} > > > > > > Recipient of repurposed protocol element sends first SETTINGS parameter > SETTINGS_ENABLE_{feature} with value > > 1 ({feature}_AVAILABLE). > > > > > > Sender of repurposed protocol element sends SETTINGS parameter > SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature}) before it starts > sending repurposed protocol element. > > > > > > Recipient interprets protocol element without {feature} > > until it receives SETTINGS parameter SETTINGS_ENABLE_{feature} > > with value 3 (SENDING_{feature}). > > > > > > Sending SETTINGS parameter SETTINGS_ENABLE_{feature} with > > value 3 (SENDING_{feature}) is protocol violation unless > > SETTINGS parameter SETTINGS_ENABLE_{feature} with value > > 1 ({feature}_AVAILABLE) or 3 (SENDING_{feature}) is received > > first. > > > > Both directions needs separately send SETTINGS parameter > > SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature}) > > before repurposed protocol element can be sent. > > > > SETTINGS parameter SETTINGS_ENABLE_{feature} value 3 (SENDING_{feature}) > > imply total ordering of frames, so this means HTTP/2. ( Also > > HTTP/3 do not allow several SETTINGS frames.) > > > > SETTINGS frame with parameter SETTINGS_ENABLE_{feature} with > > value 3 (SENDING_{feature}) indicates time when change > > on purpose of protocol element happens. > > > > It is not just enough to know that change is acceptable > > for recipient. Recipient must know when change happens. > > > > Introducing of new protocol elements do not require > > sending SETTINGS parameter SETTINGS_ENABLE_{feature} > > with value 3 (SENDING_{feature}) when frame content > > indicates precense of protocol element. > > > > / Kari Hurtta > > > > >
Received on Tuesday, 13 August 2019 19:49:11 UTC