1539819 - [socket process] TRR is not working in socket process

Status: RESOLVED FIXED

(Core :: Networking: DNS, enhancement, P2)

Description

[Kershaw Chang [:kershaw]]

In bug 1430050, we moved the DNS resolution to socket process.
However, TRR needs to create a http channel to do resolution and the http channel is designed to run in parent process.

Maybe we should move TRR back to parent process?

Comment 1

[Kershaw Chang [:kershaw]]

(In reply to Kershaw Chang [:kershaw] from comment #0)

In bug 1430050, we moved the DNS resolution to socket process.
However, TRR needs to create a http channel to do resolution and the http channel is designed to run in parent process.

Maybe we should move TRR back to parent process?

Valentin, what do you think?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

It seems to me that since nsSocketTransport lives in the socket process, we shouldn't do DNS resolution for nsSocketTransport::OnLookupComplete in the parent process, so I wouldn't want to move it.

Right now we have nsHttpChannel in the parent process, also used for TRR, and HttpChannelChild in the content process for web requests.
I'm wondering if we could have a third SocketProcessHttpChannel that does all the work in the socket process, and is used for TRR? But I have absolutely no idea how difficult that would be.

Comment 3

[Dragana Damjanovic [:dragana]]

What about opening a regular nsHttpChannel on the socket process. We will need an additional 'if IsSocketProcess use nsHttpTransaction directly'. We may need to make conditional some additional stuff, like security checks, let's see what breaks.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

We should also assert in nsHttpChannel::OnStartRequest that "if this is a TRR service channel, then we shouldn't have any cache entry".

Comment 5

[Valentin Gosu [:valentin] (he/him)]

So, a couple of notes from the meeting:

We'll try to use nsHttpChannel in the socket process exclusively for TRR once we have cert validation working.
We need to make sure we bypass the cache completely in the socket process (because it lives in the main process)
What do we do for proxy checks (for the TRR connection)? We'll initially do the check in the main process, but we'll try to optimize it later.

Comment 6

[Kershaw Chang [:kershaw]]

Attachment: Bug 1539819 - P2: Introduce PProxyConfigLookup.ipdl for get proxy config in TRRServiceChannel

Comment 7

[Kershaw Chang [:kershaw]]

Attachment: Bug 1539819 - P3: Some adjustments to make TRRServiceChannel work on socket process

Depends on D68398

Comment 8

[Kershaw Chang [:kershaw]]

Attachment: Bug 1539819 - P1: Make TRRService work in socket process

Depends on D68399

Comment 9

[Kershaw Chang [:kershaw]]

Attachment: Bug 1539819 - P4: Some adjustments to pass trr test

Depends on D68880

Comment 10

[Kershaw Chang [:kershaw]]

Attachment: Bug 1539819 - P5: Extract the logic of processing TRRService URI

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d23855057df7
P1: Make TRRService work in socket process r=dragana,necko-reviewers
https://hg.mozilla.org/integration/autoland/rev/3c13d25cab1e
P2: Introduce PProxyConfigLookup.ipdl for get proxy config in TRRServiceChannel r=dragana
https://hg.mozilla.org/integration/autoland/rev/d332f00b2ada
P3: Some adjustments to make TRRServiceChannel work on socket process r=dragana,necko-reviewers
https://hg.mozilla.org/integration/autoland/rev/a0f338331b41
P4: Some adjustments to pass trr test r=dragana,necko-reviewers
https://hg.mozilla.org/integration/autoland/rev/7c84257e93be
P5: Extract the logic of processing TRRService URI r=valentin

Comment 12

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/d23855057df7
https://hg.mozilla.org/mozilla-central/rev/3c13d25cab1e
https://hg.mozilla.org/mozilla-central/rev/d332f00b2ada
https://hg.mozilla.org/mozilla-central/rev/a0f338331b41
https://hg.mozilla.org/mozilla-central/rev/7c84257e93be