gecko-dev/netwerk/ipc/PNecko.ipdl

183 lines
6.7 KiB
Plaintext
Raw Normal View History

2009-08-18 19:05:15 +00:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set sw=2 ts=8 et tw=80 ft=cpp : */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
2009-08-18 19:05:15 +00:00
include protocol PContent;
include protocol PHttpChannel;
include protocol PCookieService;
include protocol PBrowser;
include protocol PWyciwygChannel;
include protocol PFTPChannel;
include protocol PWebSocket;
include protocol PWebSocketEventListener;
include protocol PTCPSocket;
include protocol PTCPServerSocket;
include protocol PUDPSocket;
include protocol PDNSRequest;
include protocol PChannelDiverter;
include protocol PFileDescriptorSet;
include protocol PDataChannel;
include protocol PSimpleChannel;
include protocol PTransportProvider;
include protocol PChildToParentStream; //FIXME: bug #792908
include protocol PParentToChildStream; //FIXME: bug #792908
include protocol PStunAddrsRequest;
include protocol PFileChannel;
include protocol PTrackingDummyChannel;
include IPCStream;
include URIParams;
include NeckoChannelParams;
include PBrowserOrId;
include protocol PAltDataOutputStream;
using class IPC::SerializedLoadContext from "SerializedLoadContext.h";
using mozilla::dom::TabId from "mozilla/dom/ipc/IdType.h";
using class IPC::Principal from "mozilla/dom/PermissionMessageUtils.h";
using refcounted class nsIInputStream from "mozilla/ipc/IPCStreamUtils.h";
Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin. The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test. How this works: In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent. When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel. A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call. We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process. Differential Revision: https://phabricator.services.mozilla.com/D2958 --HG-- rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs extra : moz-landing-system : lando
2018-09-04 20:45:22 +00:00
using refcounted class nsIURI from "mozilla/ipc/URIUtils.h";
2009-08-18 19:05:15 +00:00
namespace mozilla {
namespace net {
//-------------------------------------------------------------------
nested(upto inside_cpow) sync protocol PNecko
2009-08-18 19:05:15 +00:00
{
manager PContent;
2009-08-18 19:05:15 +00:00
manages PHttpChannel;
manages PCookieService;
manages PWyciwygChannel;
manages PFTPChannel;
manages PWebSocket;
manages PWebSocketEventListener;
manages PTCPSocket;
manages PTCPServerSocket;
manages PUDPSocket;
manages PDNSRequest;
manages PDataChannel;
manages PSimpleChannel;
manages PFileChannel;
manages PChannelDiverter;
manages PTransportProvider;
manages PAltDataOutputStream;
manages PStunAddrsRequest;
manages PTrackingDummyChannel;
2009-08-18 19:05:15 +00:00
parent:
async __delete__();
nested(inside_cpow) async PCookieService();
async PHttpChannel(PBrowserOrId browser,
SerializedLoadContext loadContext,
HttpChannelCreationArgs args);
async PWyciwygChannel();
async PFTPChannel(PBrowserOrId browser, SerializedLoadContext loadContext,
FTPChannelCreationArgs args);
async PWebSocket(PBrowserOrId browser, SerializedLoadContext loadContext,
uint32_t aSerialID);
async PTCPServerSocket(uint16_t localPort, uint16_t backlog, bool useArrayBuffers);
async PUDPSocket(Principal principal, nsCString filter);
async PDNSRequest(nsCString hostName, OriginAttributes originAttributes,
uint32_t flags);
async PWebSocketEventListener(uint64_t aInnerWindowID);
/* Predictor Methods */
async PredPredict(OptionalURIParams targetURI, OptionalURIParams sourceURI,
uint32_t reason, OriginAttributes originAttributes,
bool hasVerifier);
async PredLearn(URIParams targetURI, OptionalURIParams sourceURI,
uint32_t reason, OriginAttributes originAttributes);
async PredReset();
async SpeculativeConnect(URIParams uri, Principal principal, bool anonymous);
async HTMLDNSPrefetch(nsString hostname, bool isHttps,
OriginAttributes originAttributes, uint16_t flags);
async CancelHTMLDNSPrefetch(nsString hostname, bool isHttps,
OriginAttributes originAttributes,
uint16_t flags, nsresult reason);
/**
* channelId is used to establish a connection between redirect channels in
* the parent and the child when we're redirecting to a data: URI.
*/
async PDataChannel(uint32_t channelId);
async PSimpleChannel(uint32_t channelId);
async PFileChannel(uint32_t channelId);
async PChannelDiverter(ChannelDiverterArgs channel);
async PTrackingDummyChannel(nsIURI uri, OptionalLoadInfoArgs loadInfo);
/**
* These are called from the child with the results of the auth prompt.
* callbackId is the id that was passed in PBrowser::AsyncAuthPrompt,
* corresponding to an nsIAuthPromptCallback
*/
async OnAuthAvailable(uint64_t callbackId, nsString user,
nsString password, nsString domain);
async OnAuthCancelled(uint64_t callbackId, bool userCancel);
async RequestContextLoadBegin(uint64_t rcid);
async RequestContextAfterDOMContentLoaded(uint64_t rcid);
async RemoveRequestContext(uint64_t rcid);
async PAltDataOutputStream(nsCString type, int64_t predictedSize, PHttpChannel channel);
async PStunAddrsRequest();
/**
* WebExtension-specific remote resource loading
*/
async GetExtensionStream(URIParams uri) returns (nsIInputStream stream);
async GetExtensionFD(URIParams uri) returns (FileDescriptor fd);
child:
/*
* Bring up the http auth prompt for a nested remote mozbrowser.
* NestedFrameId is the id corresponding to the PBrowser. It is the same id
* that was passed to the PBrowserOrId param in to the PHttpChannel constructor
*/
async AsyncAuthPromptForNestedFrame(TabId nestedFrameId, nsCString uri,
nsString realm, uint64_t callbackId);
/* Predictor Methods */
async PredOnPredictPrefetch(URIParams uri, uint32_t httpStatus);
async PredOnPredictPreconnect(URIParams uri);
async PredOnPredictDNS(URIParams uri);
async SpeculativeConnectRequest();
// Using high priority to deliver this notification possibly sooner than we
// enter poll() on the child process with infinite timeout.
prio(high) async NetworkChangeNotification(nsCString type);
async PTransportProvider();
Bug 1476996 - Implement cross process redirection in Http on the parent process r=bagder,nika This patch builds the foundation for the ability to relocate HTTP channels from one content process to another in order to ensure that origins are properly isolated. This relocation would normally occur when the response to an HTTP request is a redirect to a different origin. The patch merely adds the mechanism for relocating the channel, rather than the logic of doing so. This will be provided in a follow-up patch by a specialized service. Right now that functionality is mocked in the test. How this works: In nsHttpChannel::OnStartRequest we will query the service that decides whether we need to direct the response to another process. If so, it will return a promise that resolves to a TabParent. When the promise resolves, in HttpChannelParentListener::TriggerCrossProcessRedirect we call NeckoParent::SendCrossProcessRedirect passing along the required information to recreate the channel in the new process. The NeckoChild in the new process will then instantiate a new channel, call ConnectParent() which creates the associated parent channel, and connects it with the existing nsHttpChannel. A listener in the new process is then notified of the existence of the new channel. It is required to call completeRedirectSetup on the channel, passing an nsIStreamListener to the call. We then finish the entire operation with a call to HttpChannelChild::SendCrossProcessRedirectDone which causes us to close the old HttpChannelChild in the previous process and to resume the nsHttpChannel in the main process. Differential Revision: https://phabricator.services.mozilla.com/D2958 --HG-- rename : netwerk/test/browser/browser_cookie_sync_across_tabs.js => netwerk/test/browser/browser_cross_process_redirect.js rename : dom/media/test/redirect.sjs => netwerk/test/browser/redirect.sjs extra : moz-landing-system : lando
2018-09-04 20:45:22 +00:00
// This message is sent to PNecko and triggers the creation of a new
// HttpChannelChild that will be connected to the parent channel represented
// by registrarId.
async CrossProcessRedirect(uint32_t aRegistrarId,
nsIURI aURI,
uint32_t aNewLoadFlags,
OptionalLoadInfoArgs aLoadInfo,
uint64_t aChannelId,
nsIURI aOriginalURI,
uint64_t aIdentifier);
both:
// Actually we need PTCPSocket() for parent. But ipdl disallows us having different
// signatures on parent and child. So when constructing the parent side object, we just
// leave host/port unused.
async PTCPSocket(nsString host, uint16_t port);
2009-08-18 19:05:15 +00:00
};
} // namespace net
} // namespace mozilla