2.1.2

Security

• A session ticket now resumes only on the listener that issued it, for
  the server name and ALPN it was issued under. Tickets were kept in one
  table for the whole VM and accepted by any listener, so a client given
  a ticket by one listener could log in to any other listener in the
  same VM, including one that only admits clients holding its pre-shared
  key. (GHSA-cv3h-phw9-vfjm, CWE-287). Found by GPT Cyber.
• A listener no longer stalls when many connections close at once.
  Each closing connection made the listener scan its whole routing
  table, so a burst of short-lived connections, which anyone can open,
  kept it from accepting or routing other clients for tens of seconds.
  (GHSA-fqq7-rg4w-x69m, CWE-407). Reported by wallace0409.
• A peer can no longer fill a slow connection owner's mailbox until the
  VM runs out of memory. Stream data earned the peer new credit as soon
  as it reached the owner's mailbox, read or not. Credit now waits while
  the owner's mailbox holds more than max_owner_queue messages (1000
  by default). (GHSA-6fr7-vvrm-wf2w, CWE-770). Reported by wallace0409.
• A peer can no longer fill a slow owner's mailbox with DATAGRAMs.
  Every DATAGRAM received was sent to the owner whatever its backlog;
  the datagram_recv_queue_len cap did not limit the mailbox. DATAGRAMs
  that arrive while the owner's mailbox holds more than
  max_owner_queue messages are now dropped and counted in
  datagram_stats/1. (GHSA-gq4m-5qh3-q47h, CWE-770). Reported by
  wallace0409.

Added

• quic:set_stream_flow_control/3 and quic:consume/3: a stream in
  manual mode earns the peer credit only for the bytes the owner
  reports as processed, so the peer sends at most one stream window
  ahead of the reader.

Fixed

• An HTTP/3 server handler reading a request body now always learns
  where the body ends. A request without a body (curl sends every GET
  this way) or one ending with trailers never signalled its end to the
  handler, so a handler waiting for the body hung.
• A server that answers a request before it is fully received, then
  stops reading it (RFC 9114 Section 4.1.1), no longer resets its own
  response when the client resets the request. On a lossy link the
  reset could throw away the end of the response.