1409553 - Assertion failure: redirectParentChannel, at netwerk/protocol/http/HttpChannelParent.cpp:1035

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P2)

Description

[Bob Clary [:bc] (inactive)]

Attachment: Linux Debug Log

1. https://www.washingtonpost.com/world/national-security/black-budget-summary-details-us-spy-networks-successes-failures-and-objectives/2013/08/29/7e57bb78-10ab-11e3-8cdd-bcdc09410972_story.html

2. Assertion failure: redirectParentChannel, at /builds/worker/workspace/build/src/netwerk/protocol/http/HttpChannelParent.cpp:1035
#01: mozilla::net::PHttpChannelParent::OnMessageReceived [s3:gecko-generated-sources:3bcb6c073cc645a704e5439450308d9b4bba8c55a51d50a2d3934f1856c39504ed39f015476c07f158311fa78ec3dbf63a4b6d2183982071b2e8fac2f074947c/ipc/ipdl/PHttpChannelParent.cpp::672]
#02: mozilla::ipc::MessageChannel::DispatchAsyncMessage [ipc/glue/MessageChannel.h:635]
#03: mozilla::ipc::MessageChannel::DispatchMessage [ipc/glue/MessageChannel.cpp:2051]
#04: mozilla::ipc::MessageChannel::RunMessage [ipc/glue/MessageChannel.cpp:1896]
#05: mozilla::ipc::MessageChannel::MessageTask::Run [ipc/glue/MessageChannel.cpp:1918]
#06: nsThread::ProcessNextEvent [mfbt/Maybe.h:445]

Windows, Linux, Nightly/58, Beta/57

opt doesn't appear to crash but doesn't complete loading either.

Assertion added in bug 1015466

Comment 1

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Will try reproduce it with RR first.

Comment 2

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Open the same page in Google Chrome and Safari, the same HTTP request is blocked by browser because it tries to load insecure content in side an <iframe> in an HTTPS page.

Two issues I saw here:
1) Why does Firefox try to redirect http://www.washingtonpost.com/wp-srv/special/national/black-budget/promo/graphic.html?index=2 to the HTTPS version of this URL but not block it.

2) Why is the redirection procedure of this channel end up not opening a new HttpChannelParent to redirect to?

Comment 3

[Honza Bambas (:mayhemer)]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #2)
> Open the same page in Google Chrome and Safari, the same HTTP request is
> blocked by browser because it tries to load insecure content in side an
> <iframe> in an HTTPS page.
> 
> Two issues I saw here:
> 1) Why does Firefox try to redirect
> http://www.washingtonpost.com/wp-srv/special/national/black-budget/promo/
> graphic.html?index=2 to the HTTPS version of this URL but not block it.

strict transport security?  could be similar to bug 1391277?

> 
> 2) Why is the redirection procedure of this channel end up not opening a new
> HttpChannelParent to redirect to?

when you know this, you know how to fix this bug.  have you managed to capture a log for this?  it might tell us where is the glitch in the flow.

Comment 4

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Honza Bambas (:mayhemer) from comment #3)
> (In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment
> #2)
> > Open the same page in Google Chrome and Safari, the same HTTP request is
> > blocked by browser because it tries to load insecure content in side an
> > <iframe> in an HTTPS page.
> > 
> > Two issues I saw here:
> > 1) Why does Firefox try to redirect
> > http://www.washingtonpost.com/wp-srv/special/national/black-budget/promo/
> > graphic.html?index=2 to the HTTPS version of this URL but not block it.
> 
> strict transport security?  could be similar to bug 1391277?
Yes we did that because of update-insecure-requests. Server replies with 302 with the HTTP version of the same URL when we send the HTTPS request.
> 
> > 
> > 2) Why is the redirection procedure of this channel end up not opening a new
> > HttpChannelParent to redirect to?
> 
> when you know this, you know how to fix this bug.  have you managed to
> capture a log for this?  it might tell us where is the glitch in the flow.
Yes I have a moz log for it with tag "nsHttp:5,sync" turned on.

Comment 5

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: test.log.zip

0x7f1d54b1e2e0 is the HttpChannelParent hit that assertion
0x7f14a0ad3000 is the corresponding HttpChannelChild

It looks like a race condition to me.
"HttpChannelParent::StartRedirect" triggered for registrarId=62, but then "HttpChannelChild::OnRedirectVerifyCallback" is tiggered for registrarId=61 on the same HttpChannelChild previously.

One thing troubles me the most is that redirection procedure is triggered on the same HttpChannelParent two times, which doesn't look sane to me.

Comment 6

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

This is a bug on the interaction between HSTS redirection and Service worker.

Service worker wants to do interception check on the redirect-to URL, thus it triggers async open on the redirect-to HttpChannelChild object after redirect completed (see bug 1229369). This async open will trigger another channel redirection because server will give 301 with the http version URL. However, the redirect-to nsHttpChannel on parent side is async opened and decided to perform HSTS redirection in parallel after redirect completed. This will cause two redirection procedure run on the same HttpChannelChild object at the same time. In certain timing the redirection verification will be sent to the wrong HttpChannelParent.

Discussed with @mayhemer, the possible solution should be doing the interception check during the redirection procedure. Therefore we can prevent doing async open on a HttpChannelChild that already have IPC opened.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #6)
> Discussed with @mayhemer, the possible solution should be doing the
> interception check during the redirection procedure. Therefore we can
> prevent doing async open on a HttpChannelChild that already have IPC opened.

We very much want to remove SW interception from HttpChannelChild.  I wonder if this bug can wait for that work.

Comment 8

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

@bkelly may I know the target timeline of the removal of SW interception in child side?

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

I think we have a shot at FF59, but its possible we will miss that still.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

If you do want to proceed without waiting, I would just like to understand if there is any impact to the parent-side InterceptedHttpChannel.  I would like to avoid adding complexity to that code if we can.

Comment 11

[Intermittent Failures Robot]

1 failures in 2581 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1

Platform breakdown:

• linux64-qr: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1409553&startday=2019-06-17&endday=2019-06-23&tree=all

Comment 12

[Intermittent Failures Robot]

1 failures in 4350 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform breakdown:

• macosx1014-64: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1409553&startday=2019-09-16&endday=2019-09-22&tree=all

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 14

[Intermittent Failures Robot]

2 failures in 4530 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1
• autoland: 1

Platform breakdown:

• linux64-qr: 1
• macosx1014-64: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1409553&startday=2019-09-23&endday=2019-09-29&tree=all

Comment 15

[Bob Clary [:bc] (inactive)]

I can't reproduce on the original url on Fedora 30 locally but Bughunter can reproduce with a different url (NSFW). I re-ran the original url to see how automation handles it and it could not reproduce. The url is not that NSFW. Ping me on irc or slack for the url.

Comment 16

[Intermittent Failures Robot]

1 failures in 4516 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• try: 1

Platform breakdown:

• linux1804-64: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1409553&startday=2020-06-29&endday=2020-07-05&tree=all

Comment 17

[Bob Clary [:bc] (inactive)]

I can no longer reproduce on original url and no longer have access to the nsfw url -> WFM