Open Bug 692929 Opened 14 years ago Updated 2 years ago

Proxy Service: Ensure proxy info is same on parent/child

Categories

(Core :: Networking: Proxy, defect, P3)

Product:
Core
Component:
Networking: Proxy
Version:
10 Branch
Type:
defect

Tracking

()

People

(Reporter: sworkman, Unassigned)

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a1) Gecko/20111007 Firefox/10.0a1 Build ID: 20111007031227 Steps to reproduce: Checking proxy service APIs for bug 390304. Actual results: Not clear if proxy service is available on both child and parent Necko processes. HttpChannelChild::GetProxyInfo(nsIProxyInfo **aProxyInfo) implemented to call DROP_DEAD. Expected results: Pending investigation of proxy service initialisation on different platforms, proxy service needs to be available to both child and parent processes, on all platforms.
Chat Transcript with Jason Duell and Steve Workman: [6:24pm] sworkman: ping [6:24pm] jduell: pong [6:24pm] sworkman: hey question on e10s [6:25pm] sworkman: is nsProtocolProxyService on all procs? [6:25pm] sworkman: how do I determine this myself? [6:25pm] sworkman: or is it like the DNS Service - only available on parent? [6:25pm] jduell: Hmm, i dunno! Let me poke around... [6:25pm] sworkman: k, np [6:26pm] sworkman: where would I poke around if I were to find out for myself? [6:26pm] sworkman: i.e. where is e10s!! [6:26pm] jduell: Well, you could do something like ask for an instance of it when you're on the child--like in HttpChannelChild [6:26pm] jduell: but that still might not tell you what you want to know [6:26pm] jduell: it might exist there formally but never get used (my suspicion) and not work if you try [6:27pm] sworkman: k (HttpChannelChild now makes sense to me - child is e10s related - penny drops, connection made) [6:28pm] jduell: Yeah, the terminology was hard to pick--IPDL uses "channels" for communication btw parent and child, which made it all confusing when layered on top of necko channels [6:28pm] sworkman: yup [6:28pm] sworkman: I had just seen HttpChannelChild and HttpChannel and HttpChannelBase or something like that [6:29pm] sworkman: in my very early code explorations [6:29pm] sworkman: so, now the suffix child has meaning in that contect [6:29pm] sworkman: *context [6:29pm] sworkman: yay [6:29pm] jduell: Ah, right--so both the channels (child and parent) share a lot of code, which is in HttpBaseChannel [6:29pm] sworkman: right [6:30pm] jduell: And then there's a nsBaseChannel that was supposed to be the base channel for *all* channels (FTP, Gopher, File, etc) but HTTP never used it [6:30pm] jduell: And at this point shouldn't. [6:30pm] sworkman: back to proxy service … am I right in assuming you added the DNS service to parent and not child [6:30pm] sworkman: "added" meaning configured or setup or whatever [6:30pm] sworkman: you're Mr E10s, right? [6:31pm] jduell: I'm sort of mr e10s [6:31pm] jduell: (I came up with "e10s" as the abbreviation for "electrolysis": little known folklore) [6:31pm] jduell: I'm not sure what you're asking about DNS [6:32pm] jduell: We already have it in necko, and we dupe the whole necko stack for the child [6:32pm] jduell: i.e. we started by having the child have it's own necko stack--it's own socket transport thread, it's own DNS, everything [6:32pm] sworkman: ok ….. [6:32pm] jduell: And what we've done is gradually shut off parts of it and use IPDL to have the parent do the work [6:32pm] sworkman: I'm looking at nsHTMLDNSPrefetch::Prefetch(nsAString &hostname, PRUint16 flags) [6:33pm] jduell: This is why I suspect you'll find a "proxy service" int he child, but it may or may not do what you want [6:33pm] sworkman: which forwards DNS requests to the parent [6:33pm] sworkman: ok … right … how do I find out if it's been turned off or not? [6:33pm] jduell: re: DNS--right--we take all the places where the child wants something from the net, and shovel it off to the parent to do the real work [6:33pm] jduell: What do you want from the proxy service, by the way? [6:33pm] sworkman: "is this uri proxies?" [6:33pm] sworkman: *proxied [6:34pm] sworkman: or rather [6:34pm] sworkman: "get me proxy info - if it's null, no proxy" [6:35pm] jduell: OK, I think I may have answers for you [6:35pm] jduell: [6:35pm] sworkman: yay [6:36pm] jduell: So, we have a mConnectionInfo variable in HttpBaseChannel [6:36pm] jduell: That seems to store the proxy info [6:36pm] jduell: AFIACT [6:36pm] sworkman: right [6:36pm] jduell: when you call nsHttpChannel::GetProxyInfo, that's what you get. [6:36pm] sworkman: right [6:37pm] jduell: So, at the moment, both child/parent channels have one of those. And it's being set in HttpBaseChannel::Init [6:37pm] sworkman: ah [6:37pm] jduell: which is called with a nsProxyInfo arg. [6:38pm] jduell: Which is passed in from nsHttpHandler::NewProxiedChannel [6:39pm] jduell: which is getting the proxy arg from nsIOService::NewChannelFromURIWithProxyFlags [6:39pm] jduell: which is talking to the proxy protocol service to get the info [6:39pm] jduell: mProxyService = do_GetService(NS_PROTOCOLPROXYSERVICE_CONTRACTID); [6:39pm] sworkman: k [6:40pm] jduell: So, the next question is: where does the proxy service get its info, and is the info in the child the same as in the parent? [6:40pm] jduell: I don't know the proxy service well. Does it get it's info from a file? In that case we're probably fine just having it duped in the child [6:41pm] jduell: But if we're getting info from one of those "get my proxy info from this URL at startup" things, there's a good chance that the parent will have the real info [6:41pm] jduell: and the child's will be wrong [6:41pm] jduell: Which will mean our e10s impl is broken for proxies [6:42pm] sworkman: k [6:42pm] sworkman: hmm … I guess I'll play around with it in runtime [6:42pm] sworkman: and poke more through the code [6:42pm] sworkman: thx! [6:42pm] jduell: So you need to poke around and find out how the proxy info gets set, and determine if we need to do something where do_GetService(NS_PROTOCOLPROXYSERVICE_CONTRACTID); [6:42pm] sworkman: right [6:43pm] jduell: returns a "fake"/Child version of the service, which gets the real info from the paret. [6:43pm] jduell: Alas, you want to make sure it doesn't ever do a blocking round trip IPDL call, so the obvious solution (send all requests to parent) will not be a happy one (the clients expect the [6:43pm] jduell: answer to be sync and instant) [6:43pm] sworkman: k … that ("fake/child version") sounds like a good approach [6:44pm] jduell: I'd guess you'd be better off having the parent proxy info send a full copy of it's info to the child [6:44pm] sworkman: k [6:44pm] jduell: So the child version is always 'updated' [6:44pm] sworkman: k [6:44pm] jduell: Also, I notice that HttpChannelChild::GetProxyInfo is not implemented [6:44pm] sworkman: and you said before one time, that e10s is not enabled on the desktop, but is on Adnroid? [6:44pm] jduell: It's one of the last spots where we have DROP_DEAD in the code. [6:45pm] jduell: So you want to implement that. The cleanest fix is probably to just move the nsHttpChannel::GetProxyInfo into the HttpBaseChannel class [6:45pm] jduell: but that assumes that you can just hand out the mConnectionInfo and things will just "work" [6:46pm] jduell: which might well be possible (and the easiest fix) if you've got the fake/Child version of the proxy info service working. [6:46pm] jduell: In other words, you'll need to figure out where to put Child/Parent objects (and communication), and then the rest of the system looks unchanged. [6:46pm] jduell: So far that's always been the easiest way. [6:47pm] jduell: And yes, e10s is only in effect for now in mobile firefox (fennec). [6:47pm] sworkman: ok cool [6:47pm] jduell: If you build --enable-application=mobile on your desktop, you get a simulator that you can debug with [6:47pm] sworkman: I think for this bug all I need is to determine how to get the proxy [6:47pm] jduell: So you don't need to actually do it on Android [6:47pm] jduell: how to get proxy on the child? [6:48pm] sworkman: some of what you're saying is more about enabling proxy over e10s [6:48pm] sworkman: right, on child or parent : both [6:48pm] jduell: Not sure I understand the difference. [6:49pm] sworkman: look at nsHTMLDNSPrefetch::Prefetch(Link ... [6:49pm] sworkman: there is a call to IsNeckoChild() [6:49pm] sworkman: and how the DNS prefetch is requested is different depending on the return val of IsNeckoChild() [6:49pm] sworkman: ... [6:50pm] sworkman: so, when I'm checking for proxy info, I want to make sure I either: [6:50pm] sworkman: 1) have something similar if proxy service is on parent [6:50pm] sworkman: 2) don't worry about it because proxy service is everywhere [6:50pm] sworkman: or 3) implement something with a simple API like you suggested [6:51pm] sworkman: (same API for parent or child; underlying implementation of proxy service takes care of it) [6:51pm] sworkman: make sense? [6:51pm] jduell: If #2 (proxy is everywhere and has same info on child/parent) then you're done [6:51pm] sworkman: right [6:52pm] jduell: but I doubt it'll be true in all cases [6:52pm] sworkman: [6:52pm] sworkman: all platforms? [6:52pm] jduell: Prob true if info is read from file, not true if we get it off the net' [6:52pm] jduell: Also prob true if we get the info from the OS (IIRC we do that on some systems) [6:52pm] sworkman: right - runtime testing and code-poking needed [6:52pm] jduell: So really the case to look for is the --damn I forget the buzzwork [6:52pm] jduell: buzzword [6:53pm] jduell: When you get your proxy info at startup via a URL. [6:53pm] sworkman: ? [6:53pm] jduell: That's the one I'm worried about. [6:53pm] sworkman: ok [6:53pm] jduell: If we need to update the child to have the parent' proxy info after that happens, I think the easiest fix is just to add a IPDL msg [6:54pm] jduell: that updates the child with the new proxy info (hopefully it's easily serializable) [6:54pm] sworkman: right [6:54pm] jduell: And then everything can look the exact same otherwise. [6:54pm] sworkman: right [6:54pm] jduell: We still need to move nsHttpCHannel::GetProxyInfo into HttpBaseChannel. [6:54pm] jduell: too [6:55pm] jduell: But if that's all the work, that's pretty good. [6:55pm] jduell: Hopefully there's no need for really tight synchronization with the proxy info update [6:55pm] jduell: I.e. it's fine when the parent gets the proxy info for it to send an async msg to the child and it updates the info, and that's it [6:56pm] jduell: as opposed to "at startup stop the child from issuing any necko channels until we know the proxy info is updated" [6:56pm] jduell: Actually, that might be neeeded [6:57pm] jduell: Since when we start the browser now (non-e10s) I assume we have to block channels until we get the correct proxy info (and that's sometimes a fetch of a URI) [6:57pm] jduell: make sense? [6:57pm] sworkman: …. yes …. processing, but yes .. [6:58pm] sworkman: I think I need another bug for this one [6:58pm] sworkman: it seems like it needs dedicated, undistracted attention [6:58pm] jduell: I suppose there might be a similar need for synchronizing if/when a user changes their proxy info during browsing. But that's probably a lot easier to be slack about. [6:58pm] sworkman: if only just to understand the code on different platforms and confirm correct and desired behavior [6:59pm] jduell: They won't really expect things to work until they close the dialog and click a link, which is lots of time for IPDL to update [6:59pm] sworkman: q: is ipdl expensive for a simple boolean query? [6:59pm] jduell: Feel free to open a new bug: "Ensure proxy info is same on parent/child" and cut-and-paste this IRC chat into it. [6:59pm] sworkman: I think I will [7:00pm] jduell: re: IPDL. Depends how you do it. [7:00pm] sworkman: right - I'm thinking that after I asked the question [7:00pm] jduell: If you send an IPDL msg with a bool value, it's certainly tens of 1000s of times more expensive than just updating a bool somewhere (info needs to go down a named pipe to another process, [7:00pm] sworkman: I guess if the parent is querying a bool on it's side and able to return immediately, then it's quick [7:01pm] jduell: which receives it on the IPDL thread then sends an event to the main thread) [7:01pm] sworkman: but if the parent is querying a lot of data, data that might be mutexed/serialised … then we have potential time delay … and nasty blocking calls [7:01pm] jduell: If you want to *block* while you wait for an answer from the parent, yeah, that's totally expensive, and basically out of the question [7:01pm] jduell: Sorry! [7:01pm] jduell: Unless there's some really compelling reason why it's hard to engineer it otherwise. [7:02pm] sworkman: hehe - no sorry needed - I'll figure it out [7:02pm] sworkman: ok - Nick is asking for lunch [7:02pm] jduell: That's why I think the "keep child proxy svc updated with info from parent" is better than "ask parent each time for info and block" [7:02pm] sworkman: thx for convo - good info [7:02pm] jduell: OK, I think you've got enough info to be dangerous--enjoy!
OS: Mac OS X → All
Hardware: x86 → All
Assignee: nobody → sjhworkman
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: sjhworkman → nobody
Status: ASSIGNED → NEW
Severity: normal → S3

Moving bug to Core/Networking: Proxy.

Component: Networking → Networking: Proxy
You need to log in before you can comment on or make changes to this bug.