Re: [quicwg/base-drafts] Send complete SETTINGS (#2972)

[David Benjamin <[e-mail]>]

davidben commented on this pull request.



>  initial value of each server setting is the value used in the previous session.
-Clients MUST store the settings the server provided in the session being resumed
-and MUST comply with stored settings until the current server settings are
-received.  A client can use these initial values to send requests before the
-server's SETTINGS frame has arrived.  This removes the need for a client to wait
-for the SETTINGS frame before sending requests.
+Clients SHOULD store the settings the server provided in the connection where
+resumption information was provided. A client MUST comply with either stored
+settings -- or default values, if no values are stored -- when attempting 0-RTT.
+Once a server has provided new settings, clients MUST comply with those values.

This does smooth over the worst of this mess, but since the ordering issue is not obvious, I think it's worth calling out explicitly that the client may choose not to store the settings if things were received in the wrong order.

>  
 A server can remember the settings that it advertised, or store an
 integrity-protected copy of the values in the ticket and recover the information
 when accepting 0-RTT data. A server uses the HTTP/3 settings values in
-determining whether to accept 0-RTT data.
+determining whether to accept 0-RTT data.  If the server cannot determine that
+the settings remembered by a client are compatible with its current settings, it
+MUST NOT accept 0-RTT data.  (Remembered settings are compatible if a client
+complying with those settings would not violate the server's current settings.)

(I expect our implementation will just require an exact byte-for-byte match. It saves adding a funny callback and I wouldn't expect the values to actually change much. Same for the QUIC transport parameters.)

>  
 A server MAY accept 0-RTT and subsequently provide different settings in its
 SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST
 NOT reduce any limits or alter any values that might be violated by the client
-with its 0-RTT data.  The server MAY omit settings from its SETTINGS frame which
-are unchanged from the initial value.
+with its 0-RTT data.  The server MUST include all settings which differ from
+their default values.

What should the client do if it sees the server reduce limits or otherwise alter values?
What if it sees the server do so implicitly by omitting a non-default setting that was previously set in the remembered SETTINGS frame?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2972#pullrequestreview-278161580