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

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

This seems like the right answer to me.

I get the desire to find a more general solution, but I am concerned that we don't know what "general" looks like.  This works well enough.  It's complicated to write it down, but I don't think that it's all that complicated in practice.

> -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.
+setting is the default value.  1-RTT keys will always become available prior to
+SETTINGS arriving, even if the server sends SETTINGS immediately. Clients SHOULD
+NOT wait indefinitely for SETTINGS to arrive before sending requests, but SHOULD
+process received datagrams in order to increase the likelihood of processing
+SETTINGS before sending the first request.
+
+When a 0-RTT QUIC connection is being used, the initial value of each server
+setting is the value used in the previous session. Clients SHOULD store the
+settings the server provided in the connection where resumption information was
+provided, but MAY opt not to store settings in certain cases (e.g. if the

```suggestion
provided, but MAY opt not to store settings in certain cases (e.g., if the
```

>  
 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

```suggestion
MUST NOT accept 0-RTT data.  Remembered settings are compatible if a client
```

>  
 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.)

```suggestion
complying with those settings would not violate the server's current settings.
```

>  
 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.  If a server accepts 0-RTT, but then sends a SETTINGS
+frame which reduces a setting the client understands or omits a value that was
+previous specified, this MUST be treated as a connection error of type

```suggestion
previously specified to have a non-default value, this MUST be treated as a connection error of type
```

The "ly" is just grammar, but I think that it would be OK to have a server send a default value in connection 1 and omit the value in connection 2.

-- 
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-279891170