Closed Bug 1345240 Opened 3 years ago Closed 3 years ago
h2 stalls on failed early data hard reload
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.
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+
You need to log in before you can comment on or make changes to this bug.