require the application to handle 0-RTT rejection

[marten-seemann]

Fixes #2067. Depends on #3073.

Implementing the proposal made in this issue, without the wrapper for the easy / common case.

[codecov]

Codecov Report

Merging #3066 (f8313d8) into master (eb3e100) will decrease coverage by 0.19%.
The diff coverage is 68.69%.

@@            Coverage Diff             @@
##           master    #3066      +/-   ##
==========================================
- Coverage   86.04%   85.85%   -0.19%     
==========================================
  Files         132      132              
  Lines        9435     9513      +78     
==========================================
+ Hits         8118     8167      +49     
- Misses        955      981      +26     
- Partials      362      365       +3     

Impacted Files	Coverage Δ
internal/ackhandler/sent_packet_handler.go	77.69% <ø> (-0.17%)	⬇️
session.go	75.92% <0.00%> (-0.68%)	⬇️
internal/flowcontrol/connection_flow_controller.go	95.35% <71.43%> (-4.65%)	⬇️
streams_map.go	84.97% <72.73%> (-8.37%)	⬇️
framer.go	97.50% <88.24%> (-2.50%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb3e100...f8313d8. Read the comment docs.

[lucas-clemente]

I find it hard to understand which parts of the streamsMap are expected to be thread safe, probably some comments would help.

That said, this looks weird to me: The error is set from ResetFor0RTT and read from the Open* / Accept* fns. So those are called from different threads? But then, they read the maps, which are set from initMaps, called from ResetFor0RTT? Why does the error need to be protected, but not those maps?

[marten-seemann]

Open and Accept is called by the application. When 0-RTT is reset, these calls should return Err0RTTRejected, until the application calls NextSession.
initMaps is called after the error is set, so we don't need introduce a mutex for Open and Accept. Note that ResetFor0RTT also closes the maps, which makes them return an Err0RTTRejected if Open or Accept is called concurrently.

[lucas-clemente]

So ResetFor0RTT and Open* are called from different threads? Then I don't think this is safe. Imagine the thread calling Open* pauses after the err != nil if clause, then ResetFor0RTT is called, starts setting the new map, gets interrupted and the first thread resumes – concurrent access to the map without protection?

[marten-seemann]

@lucas-clemente I introduced a mutex in the streams_map. PTAL.

[kaiyuhou]

Hi, I noticed the current http3 client would not handle the "0-RTT rejected" correctly. The http3 client will only raise the error to the user if it received this error and will not resend the request.

Or do I have the wrong expectation for the http3 client? Should It be defined as an application? If it shouldn't be considered as an application, as an end-user when I received the "0-RTT rejected" error from the http3 client, should I manually call the "Do" function again?

In this case, will the first data packet be the "1-RTT" case, or actually the "2-RTT" case?