Closed Bug 1236170 Opened 5 years ago Closed 5 years ago
Site not redirecting (HTTP/2
.0) [push cache not found]
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
Status: UNCONFIRMED → NEW
Component: General → Networking: HTTP
Ever confirmed: true
Product: Firefox → Core
Summary: [e10s] Site not redirecting → [e10s] Site not redirecting (HTTP/2.0)
Version: 44 Branch → 42 Branch
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]
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)
Filed bug 1236650 for the push cache not found portion of the issue
Attachment #8703788 - Flags: review?(mcmanus) → review+
e10s is off by default in Fx44, tracked for fx45
please nom for 45
This appears to affect both e10s and non-e10s enabled browsers, so we should probably at least think about uplifting further than 45.
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
Jonathan, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
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.
All redirects now working. Tried nightly from original caniuse link I initially hit bug with.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.