1019921 - http/2 padding test problem

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Patrick McManus [:mcmanus]]

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

https://http2.iijplus.jp/padding

Firefox did not show the contents and left blank.

The debug log of Firefox is uploaded in

https://gist.github.com/shigeki/a3254ee309ff858745dc

but there not seemed to have a specific error in it.

Comment 1

[u408661]

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.

Comment 2

[Patrick McManus [:mcmanus]]

does the fin/end-of-stream get found?

Comment 3

[Patrick McManus [:mcmanus]]

or a mismatched content length?

Comment 4

[u408661]

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 :)

Comment 5

[u408661]

Attachment: patch

Here we go. Works fine with the test case in the bug report, and continues to work fine with my previous test case.

https://tbpl.mozilla.org/?tree=Try&rev=9dddd8f2604f

Comment 6

[u408661]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/4b3198fb55a0

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4b3198fb55a0