1236170 - Site not redirecting (HTTP/2.0) [push cache not found]

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Jonathan Howard]

Try to visit https://www.chromestatus.com/
Does not load with e10s.
No errors, stays on previous page after load stops.
Can see status in network dev tools.
Probably HTTP/2.0 related.

Comment 1

[Loic]

Reg range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=156ce2d8efbf648771d56544caae5a1591881d58&tochange=150530c5d172f709b8ba36432ceefe72788560a5

Nate Hughes — Bug 1136727 - Validate pseudo-header fields in HTTP/2. r=hurley

Comment 2

[Patrick McManus [:mcmanus]]

its a push but we can't find the pushcache

Comment 3

[Patrick McManus [:mcmanus]]

16-01-04 15:32:39.925529 UTC - 1037526784[7fda5849c340]: Http2Session::RecvPushPromise 7fda28fa4000 ID 0x2 assoc ID 0xF paddingLength 0 padded 0
2016-01-04 15:32:39.925541 UTC - 1037526784[7fda5849c340]: Http2Session::RecvPushPromise Push Recevied without push cache
2016-01-04 15:32:39.925548 UTC - 1037526784[7fda5849c340]: Http2Session::GenerateRst 7fda28fa4000 0x2 7
2016-01-04 15:32:39.925556 UTC - 1037526784[7fda5849c340]: Http2Session::LogIO 7fda28fa4000 stream=0 id=0x0 [Generate Reset]
2016-01-04 15:32:39.925565 UTC - 1037526784[7fda5849c340]: 00000000: 00 00 04 03 00 00 00 00 02 00 00 00 07
2016-01-04 15:32:39.925572 UTC - 1037526784[7fda5849c340]: nsSocketOutputStream::Write [this=7fda1de6cdf0 count=13]
2016-01-04 15:32:39.925580 UTC - 1037526784[7fda5849c340]:   calling PR_Write [count=13]
2016-01-04 15:32:39.925624 UTC - 1037526784[7fda5849c340]: [7fda1ef66c70] wrote 13 bytes
2016-01-04 15:32:39.925637 UTC - 1037526784[7fda5849c340]:   PR_Write returned [n=13]
2016-01-04 15:32:39.925643 UTC - 1037526784[7fda5849c340]: JIMB: ReleaseFD_Locked: mFDref = 2
2016-01-04 15:32:39.925650 UTC - 1037526784[7fda5849c340]: nsSocketTransport::SendStatus [this=7fda1de6cc00 status=804b0005]
2016-01-04 15:32:39.925659 UTC - 1037526784[7fda5849c340]: Http2Session::FlushOutputQueue 7fda28fa4000 sz=13 rv=0 actual=13
2016-01-04 15:32:39.925680 UTC - 1037526784[7fda5849c340]: Http2Decompressor::DoLiteralInternal indexed name 1 :authority
2016-01-04 15:32:39.925694 UTC - 1037526784[7fda5849c340]: DecodeFinalHuffmanCharacter trying to chain when we're out of bits
2016-01-04 15:32:39.925701 UTC - 1037526784[7fda5849c340]: CopyHuffmanStringFromInput decoded a full string!
2016-01-04 15:32:39.925708 UTC - 1037526784[7fda5849c340]: Http2Decompressor::DoLiteralInternal value www.chromestatus.com
2016-01-04 15:32:39.925718 UTC - 1037526784[7fda5849c340]: HTTP Decompressor found illegal response pseudo-header :authority

Comment 4

[Patrick McManus [:mcmanus]]

so the real question here is why can't we find the push cache on e10s for this test case? (which is why we reset the push).. Nick I think you recently worked on another bug that manifested like that..

Also, uncompressanddiscard() called from recvpushpromise() needs to learn that its from a push so it can set the "isPush" bool to the decoder correctly - which would prevent us from throwing this error even if we are refusing the push stream for some reason.

Comment 5

[u408661]

Attachment: patch

Pat - thanks for doing the heavy lifting for me to figure out the fix for the big problem (site never loads). This patch takes care of that. Let's leave this bug for that problem, and I'll clone this to a second bug to investigate the push cache not found issue - that issue isn't a show-stopper, just sub-optimal.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d527ba05cf5

Comment 6

[u408661]

Filed bug 1236650 for the push cache not found portion of the issue

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ef0cfe8a2f77

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

e10s is off by default in Fx44, tracked for fx45

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ef0cfe8a2f77

Comment 10

[Patrick McManus [:mcmanus]]

please nom for 45

Comment 11

[u408661]

This appears to affect both e10s and non-e10s enabled browsers, so we should probably at least think about uplifting further than 45.

Comment 12

[u408661]

Comment on attachment 8703788 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: Bug 1136727
[User impact if declined]: Some sites (at least www.chromestatus.com) may not load
[Describe test coverage new/current, TreeHerder]: on m-c
[Risks and why]: Low risk - this was an oversight in the original patch, and just (appropriately) disables certain validation paths for headers received in h2 pushes that are being thrown away.
[String/UUID change made/needed]: none

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Jonathan, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

Comment 14

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8703788 [details] [diff] [review]
patch

Uplifting to Aurora45. It's unclear how many sites are affected, and given that this has been around since 42, I am leaning towards rejecting this for Beta44. On win8 44.0b6, I tried STR and was able to load chromestatus.com.

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/aa83b5c43598

Comment 16

[Jonathan Howard]

All redirects now working.
Tried nightly from original caniuse link I initially hit bug with.

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this was a regression, though it's already fixed.