1287225 - Implement WebRTC HTTP proxy support in e10s parent

Status: RESOLVED INCOMPLETE

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

Description

[Nils Ohlmeier [:drno]]

To facilitate bug 1285330 we are going to implement an HTTP proxy client in the e10s parent process.

We will have to create a new IPC interface. WebRTC from the content child process will look up the proxy information and pass that information together with the destination TURN server over the new IPC interface to the e10s parent process. The code in the parent process will take care of doing the HTTP connect request, hopefully including client authentication if needed. Once the code has received a 200 from the proxy it will have to return a TCP stream back to the client process, which is what the web socket support is doing already.

Once the HTTP connection has been turned into a TCP stream the filtering code from bug 1244926 should be enforced again per bug 1285330.

Comment 1

[Nils Ohlmeier [:drno]]

Could you provide me with pointers to the Necko proxy code which I need to instrument and the WebSocket code where a TCP connections gets handed back to the client after the HTTP upgrade?

Comment 2

[Patrick McManus [:mcmanus]]

you can look at httpbasechannel::httpupgrade and the corresponding idl and its usage in nsHttpChannel and nsHttpConnectionMgr::CompleteUpgrade for some starters on the websocket side. (101 upgrade responses are how you turn a http response into a byte stream of some other protocol)

CONNECT tunnels are made in 2 different places - one for h1 and one for h2.. for h1 you can look at what is downstream from nsHttpConnection::SetupProxyConnect.. for h2 look at http2session::dispatchontunnel..

the upgrade stuff is a pretty tight match to what you need (I suspect) - the CONNECT stuff is pretty tightly tied to putting another http transaction onto the subsequent tunnel so is going to require more flexibility.

Comment 3

[Nils Ohlmeier [:drno]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ac0c0a057d10

Comment 4

[Shay]

Hi, any updates - estimated time for the fix maybe?
Thank you

Comment 5

[trankkilou]

Hi,

Can you give an estimate date of proxy authen working with TURN server (not STURN) ?

this is a typical scenario in company where you are obliged to use a HTTP(S) proxy with (basic most of the time) authentication to get out on the NET.

Firefox works far better than chrome in decoding RTP packet in webrtc (less delay, no stuttering) so I'm mad not being able to use FF instead of chrome.

I can provide what you need as log, pcap etc...

Comment 6

[Guillaume Leroux]

Hi, many big companies trying to implement webRTC services across the intranet / internet border are currently bumping into this, as their security officer makes it mandatory to have all outbound requests authenticated (basic or Kerberos). One of the only solutions is now to use Chrome, not satisfactory as not open source.
I’m also asking for an estimate date ? Especially, could this be implemented before the next ESR (i.e. 59)?
Out of curiosity, can companies foster some bug fixes by funding them, if so how ?

Comment 7

[Nils Ohlmeier [:drno]]

This ticket dropped of the radar for some time, because this appeared to be double effort assuming we would move mtransport into it's own process. But recent discussions showed that we need this solution even if we do that.

Right now I would say we want to get this done within 2017, but we have no start date.

Comment 8

[Nils Ohlmeier [:drno]]

:jduell: this is the bug we talked about last week. It probably makes sense to actually break off another bug first for the changes in Necko, and make this one blocking on that work.

Comment 9

[Shay]

Hi, Any news with regard this item? When is it going to be fixed?

Comment 10

[Rob Hainer]

TokBox is seeing more and more from Enterprises committed to using Firefox that need this feature.

Comment 11

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 12

[Daniel]

Would be great if someone can come around to this at one point. Many companies have issues since their proxies doing NTLM and Kerberos.

Comment 13

[saif.tareq]

Just so that I'm understanding this correctly:
1) There is some proxy service (presumably something that comes with Windows Server)
2) Clients can not use WebRTC based software (e.g. Google Hangouts) while connected to the proxy service
If this is not correct, please provide an example.

Comment 14

[Nils Ohlmeier [:drno]]

I don't have the capacity any more to work on this any time soon.

Comment 15

[Nils Ohlmeier [:drno]]

Actually lets close this once, since a working patch exists in bug 1203503.