Re: Add new "network channel about to connect" event to nsIObserverService?

On 08/11/2012 12:19 AM, Christian Biesinger wrote:
>
> Hrm yeah, there's two issues:
> - socket transports have a different concept of "connect" than channels do
> - how do you map from a socket transport to the active channel, 
> whatever that means
>
> Still I'm very hesitant to make an event generic to all channels. 
> There is no central point that can handle sending it. Can we just give 
> ftp and websockets their own version of the event?
>

I'm agnostic on the "central point" issue--if necko doesn't guarantee 
that all network requests trigger one central event type, then we're 
just shoving the responsibility to catch all types of network traffic 
onto the client(s) that want to monitor it, who are more likely to get 
it wrong.

That said, the fastest way to make progress here is to just give ftp its 
own 'ftp-on-modify-request' and be done with this for now. Websockets 
bootstrap from an HTTP request, so the regular http on-modify-request 
event is enough to catch them (the appID will still be gettable from the 
HTTP channel's callbacks).

biesi: thanks for replying while you're in Hawaii :)

Patrick (Wang, not mcmanus :) : -go ahead and get started hooking 
http-on-modify-request: (Cancel() the channel if it's not allowed to use 
the network)

    https://developer.mozilla.org/en-US/docs/Observer_Notifications

Note that while HTTP channels send out 'http-on-modify-request' on both 
parent/child, websockets currently only trigger that event on the 
parent--let me know if that's an issue, but it would be non-trivial to 
change that.  So I'd recommend doing the policy checks on the parent 
process if possible.

I've also added a new bug for the FTP notification:

   https://bugzilla.mozilla.org/show_bug.cgi?id=782085

You could probably knock off that bug yourself--just copy how 
nsHttpHandler::OnModifyRequest works (and see the calls to it from 
nsHttpChannel and HttpChannelChild, and copy to the FTP channels).

Jason


> On Aug 10, 2012 9:00 PM, "Patrick Wang" <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Hi,
>
>     We also need to know which app is attempting to open a channel.
>     AFAIK, it might be difficult to know the app information (app id)
>     if we implement this event in SocketTransport. As a
>     SocketTransport instance is not belong to a single app and can be
>     reused by nsHttpChannels form various apps.
>
>     Patrick
>
>     ----- Original Message -----
>     From: "Christian Biesinger" <[email protected]
>     <mailto:[email protected]>>
>     To: "Jason Duell" <[email protected] <mailto:[email protected]>>
>     Cc: "Jonas Sicking" <[email protected]>,
>     [email protected]
>     <mailto:[email protected]>, "Patrick Wang"
>     <[email protected] <mailto:[email protected]>>, "Boris Zbarsky"
>     <[email protected] <mailto:[email protected]>>
>     Sent: 2012年8月11日 星期六 14:05:51
>     Subject: Re: Add new "network channel about to connect" event to
>     nsIObserverService?
>
>
>
>     I can't look at bugzilla right now, but I think you're better off
>     to add this to the socket transport service. Just because channels
>     can be implemented by lots of things but there's only one socket
>     transport service, that way you're guaranteed to catch all network
>     activity.
>
>     Written on my phone will jelly bean voice recognition. Results
>     were dubious.
>     On Aug 10, 2012 12:49 PM, "Jason Duell" < [email protected]
>     <mailto:[email protected]> > wrote:
>
>
>     In
>
>     https://bugzilla.mozilla.org/ show_bug.cgi?id=780087
>
>     we'll be blocking B2G app's traffic if they exceed a quota, and/or
>     only allow it if the phone is in a wifi network, etc.
>
>     Honza came up with the idea of adding a CSP policy to do this
>     monitoring, but sicking comments on IRC that "putting it in the
>     CSP code sounds like a scary hack though given that it's not CSP
>     code at all". So perhaps CSP is a bad place for it.
>
>     We could use http-on-modify-request, but that only fires for HTTP
>     requests.
>
>     I'm currently thinking we might want to add a new
>     nsIObserverService notification that's issued for "necko channel
>     for app AppID about to connect on network interface FOO". How does
>     that sound? Am I missing some other clever way of doing this?
>
>     Jason
>

_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network