Closed Bug 1019921 Opened 5 years ago Closed 5 years ago

http/2 padding test problem


(Core :: Networking: HTTP, defect)

29 Branch
Not set





(Reporter: mcmanus, Assigned: u408661)


(Whiteboard: [spdy][http2release])


(1 file)

. Padding page is not shown.
When I accessed the page with padding as

Firefox did not show the contents and left blank.

The debug log of Firefox is uploaded in

but there not seemed to have a specific error in it.
Whiteboard: [spdy] → [spdy][http2release]
So I took a look at the log referenced above, and see nothing out of the ordinary. All the parsing of padding on both HEADERS and DATA frames seems to go off without a hitch - the headers come out as expected, and we get the right amount of real data out of the padded DATA frame and pass that on to the transaction, and we finish the stream via ResetDownstreamState.

But, as in the initial report, the page just stays blank (actually, it never "finishes" loading - the spinner keeps spinning until I hit escape or quit, even though the full stream is downloaded).

I ran the test locally, and got effectively the same log as linked above (though the padding sizes were different, I guess the server is doing random large amounts of padding). The only odd thing I saw at all in the log was we appear to be shooting off 2 requests for /favicon.ico (on streams 5 and 7), though I feel like that might be something I've seen previously, so maybe it's not that odd.

The only difference between this and other padding tests I've done is that this has a LOT of padding (like, 8k+ of padding). But, like I said, we seem to parse it fine, and hand off the data to the transaction just fine, we just get hung up sometime after nsHttpTransaction::HandleContent gets called.

I'll keep digging to see if I can find out where we get off the rails.
does the fin/end-of-stream get found?
or a mismatched content length?
We do see EOS, and the content length matches, but we never seem to be calling CleanupStream when we have a frame that has all 3 of data, padding, AND EOS set on it. (Previous tests would always end with a runt frame of just padding and EOS.) I have to track down the actual source of the mess-up here (and the proper place to fix it) after I get back in front of a keyboard, but at least I know what I'm looking for :)
Assignee: nobody → hurley
Attached patch patchSplinter Review
Here we go. Works fine with the test case in the bug report, and continues to work fine with my previous test case.
Attachment #8433728 - Flags: review?(mcmanus)
Attachment #8433728 - Flags: review?(mcmanus) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.