after early data fails but alpn stays the same we just rewind the serialized data and retransmit, but after that retransmit we don't resumeRecv() as we would have after a normal stream send worked.. that in turn means we don't notice the reply until something else happens to put us in a read state.
https://hg.mozilla.org/integration/mozilla-inbound/rev/79c244d2866e5220ec809da0dbc258de76635688 Bug 1345240 - Trigger Reads After FlushWrite with no new writable streams in h2 r=hurley
this impacts early data which is on 54 but preffed off. we should consider porting it there.
status-firefox53: --- → wontfix
status-firefox54: --- → affected
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Comment on attachment 8844613 [details] [diff] [review] Trigger Reads After FlushWrite with no new writable streams in h2 Approval Request Comment [Feature/Bug causing the regression]: 1322373 (landed on 54) [User impact if declined]: http transactions using 0rtt tls 1.3 might contain big stalls [Is this code covered by automated tests?]: exercised by tests [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: no [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: very low risk [Why is the change risky/not risky?]: adds a check to flush a buffer - always an ok thing to do [String changes made/needed]: none
Attachment #8844613 - Flags: approval-mozilla-aurora?
Comment on attachment 8844613 [details] [diff] [review] Trigger Reads After FlushWrite with no new writable streams in h2 Fix possible stall when using 0rtt tls 1.3 in http transaction. Aurora54+.
Attachment #8844613 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox54: affected → fixed
You need to log in before you can comment on or make changes to this bug.