Open Bug 1409553 Opened 2 years ago Updated 21 days ago

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

Categories

(Core :: Networking, defect, P2)

58 Branch
defect

Tracking

()

Tracking Status
firefox57 --- affected
firefox58 --- affected

People

(Reporter: bc, Assigned: schien)

References

(Blocks 1 open bug, )

Details

(Keywords: assertion, intermittent-failure, regression, Whiteboard: [necko-triaged])

Attachments

(2 files)

Attached file 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
Will try reproduce it with RR first.
Assignee: nobody → schien
Priority: -- → P2
Whiteboard: [necko-triaged]
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?
(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.
(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.
Attached file 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.
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.
(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.
@bkelly may I know the target timeline of the removal of SW interception in child side?
Flags: needinfo?(bkelly)
I think we have a shot at FF59, but its possible we will miss that still.
Flags: needinfo?(bkelly)
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.

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

Keywords: regression
You need to log in before you can comment on or make changes to this bug.