Closed
Bug 1167851
Opened 9 years ago
Closed 8 years ago
HTTP/2 pushes and WINDOW_UPDATE frame
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: v.v.biriukov, Unassigned, NeedInfo)
References
Details
(Whiteboard: [spdy])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 YaBrowser/15.4.2272.3420 (beta) Safari/537.36 Actual results: I'm testing http2 pushed and get stuck with an issues that sometimes FF stops sending WINDOW_UPDATE frames on push streams. Because of this user can't get full loaded pages with pushed content. In Wireshark it looks https://yadi.sk/i/NoLCB-04gpYPj I haven't got steps to reproduce right now. I'm tryiing to push images around 1MB.
Comment 1•9 years ago
|
||
Hi - thanks for filing the report. We would need to dig into the use case and STR to figure out if there was really a bug here. Firefox will indeed stall a largeish pushed stream via flow control if it has already buffered a bunch of it and it does not know whether or not it will actually need the resource. "need" is generally determined by something in firefox requesting the pushed uri - when that happens the window should open back up again. If it doesn't happen within some timeout the stream should be canceled. As long as the server provides the same resource via push and pull this shouldn't result in a partially loaded page - that would be a bug. but to go further we would need more information on how to reproduce.
Whiteboard: [spdy]
Updated•9 years ago
|
Flags: needinfo?(v.v.biriukov)
Summary: HTTP/2 pushes and WINDOW_UPDATA frame → HTTP/2 pushes and WINDOW_UPDATE frame
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•