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
