So @huitema, I'm seeing some weird behaviour now... if I test 0-RTT back-to-back (so open 1 connection to get a session ticket, then immediately use that for the 2nd connection with 0-RTT) all seems ok
8:39
Yet, if I instead store the ticket in a file and later (say 1 minute after) attempt 0-RTT with that, it fails with "Header of encryption error 429." (e.g., https://test.privateoctopus.com/cgi-bin/test.pl?name=75faaf8403c668d9) (edited)
8:41
I do get proper 0-RTT working with the second method with other stacks, so it doesn't immediately seem to be a client-side problem (though it's of course still possible)
huitema 8:51 AM
This is consistent with the session ticket not validated for 0rtt. Resumption worked. Did you send the value of the NEW TOKEN, or a repeat of the RETRY TOKEN?
rmarx 8:51 AM
I didn't send any token
8:51
just used the session ticket
8:52
and I also don't send tokens in the "back-to-back" scenario
So @huitema, I'm seeing some weird behaviour now... if I test 0-RTT back-to-back (so open 1 connection to get a session ticket, then immediately use that for the 2nd connection with 0-RTT) all seems ok 8:39 Yet, if I instead store the ticket in a file and later (say 1 minute after) attempt 0-RTT with that, it fails with "Header of encryption error 429." (e.g., https://test.privateoctopus.com/cgi-bin/test.pl?name=75faaf8403c668d9) (edited) 8:41 I do get proper 0-RTT working with the second method with other stacks, so it doesn't immediately seem to be a client-side problem (though it's of course still possible)
huitema 8:51 AM This is consistent with the session ticket not validated for 0rtt. Resumption worked. Did you send the value of the NEW TOKEN, or a repeat of the RETRY TOKEN?
rmarx 8:51 AM I didn't send any token 8:51 just used the session ticket 8:52 and I also don't send tokens in the "back-to-back" scenario