Closed Bug 1236170 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Networking: HTTP, defect)

42 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla46
Tracking Status
firefox42 --- affected
firefox43 --- affected
firefox44 - wontfix
firefox45 + fixed
firefox46 + fixed

People

(Reporter: jonathan, Assigned: u408661)

References

Details

(Keywords: regression, site-compat)

Attachments

(1 file)

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.
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
Blocks: 1136727, e10s
Status: UNCONFIRMED → NEW
Component: General → Networking: HTTP
Ever confirmed: true
Flags: needinfo?(hurley)
Keywords: regression
Product: Firefox → Core
Summary: [e10s] Site not redirecting → [e10s] Site not redirecting (HTTP/2.0)
Version: 44 Branch → 42 Branch
Keywords: site-compat
its a push but we can't find the pushcache
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
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.
Assignee: nobody → hurley
Summary: [e10s] Site not redirecting (HTTP/2.0) → [e10s] Site not redirecting (HTTP/2.0) [push cache not found]
Attached patch patchSplinter Review
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
Attachment #8703788 - Flags: review?(mcmanus)
Blocks: 1236650
Filed bug 1236650 for the push cache not found portion of the issue
Flags: needinfo?(hurley)
Attachment #8703788 - Flags: review?(mcmanus) → review+
e10s is off by default in Fx44, tracked for fx45
https://hg.mozilla.org/mozilla-central/rev/ef0cfe8a2f77
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
please nom for 45
Flags: needinfo?(hurley)
This appears to affect both e10s and non-e10s enabled browsers, so we should probably at least think about uplifting further than 45.
Flags: needinfo?(hurley)
Summary: [e10s] Site not redirecting (HTTP/2.0) [push cache not found] → Site not redirecting (HTTP/2.0) [push cache not found]
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
Attachment #8703788 - Flags: approval-mozilla-beta?
Attachment #8703788 - Flags: approval-mozilla-aurora?
Jonathan, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(jonathan)
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.
Attachment #8703788 - Flags: approval-mozilla-beta?
Attachment #8703788 - Flags: approval-mozilla-beta-
Attachment #8703788 - Flags: approval-mozilla-aurora?
Attachment #8703788 - Flags: approval-mozilla-aurora+
All redirects now working.
Tried nightly from original caniuse link I initially hit bug with.
Flags: needinfo?(jonathan)
Status: RESOLVED → VERIFIED
Tracking since this was a regression, though it's already fixed.
You need to log in before you can comment on or make changes to this bug.