RE: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities

[Mike Bishop <[e-mail]>]

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.



-----Original Message-----
From: Kari Hurtta <[e-mail]>
Sent: Saturday, August 3, 2019 3:58 AM
To: Lucas Pardue <[e-mail]>; HTTP Working Group <[e-mail]>
Cc: Kari Hurtta <[e-mail]>; HTTP Working Group <[e-mail]>; Matthew Kerwin <[e-mail]>; Brad Lassey <[e-mail]>; Dmitri Tikhonov <[e-mail]>
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