Closed Bug 1539819 Opened 2 years ago Closed 4 months ago

[socket process] TRR is not working in socket process

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: kershaw, Assigned: kershaw)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(5 files)

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?

(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?

Flags: needinfo?(valentin.gosu)

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.

Flags: needinfo?(valentin.gosu)
Priority: -- → P2
Whiteboard: [necko-triaged]

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.

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

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.

Depends on D68880

Assignee: nobody → kershaw
Status: NEW → ASSIGNED
Attachment #9136010 - Attachment description: Bug 1539819 - P1: Add PProxyConfigLookup ipdl → Bug 1539819 - P2: Polling proxy info
Attachment #9136909 - Attachment description: Bug 1539819 - P3: Make TRRService work in socket process → Bug 1539819 - P1: Make TRRService work in socket process
Attachment #9136011 - Attachment description: Bug 1539819 - P2: Some adjustments to make TRRServiceChannel work on socket process → Bug 1539819 - P3: Some adjustments to make TRRServiceChannel work on socket process
Attachment #9136010 - Attachment description: Bug 1539819 - P2: Polling proxy info → Bug 1539819 - P2: Introduce PProxyConfigLookup.ipdl for get proxy config in TRRServiceChannel
Pushed by kjang@mozilla.com:
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
You need to log in before you can comment on or make changes to this bug.