gecko-dev/ipc/glue/URIUtils.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

49 строки
1.4 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* 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/. */
#ifndef mozilla_ipc_URIUtils_h
#define mozilla_ipc_URIUtils_h
#include "mozilla/ipc/URIParams.h"
#include "mozilla/ipc/IPDLParamTraits.h"
#include "nsCOMPtr.h"
#include "nsIURI.h"
namespace mozilla {
namespace ipc {
void SerializeURI(nsIURI* aURI, URIParams& aParams);
void SerializeURI(nsIURI* aURI, Maybe<URIParams>& aParams);
already_AddRefed<nsIURI> DeserializeURI(const URIParams& aParams);
already_AddRefed<nsIURI> DeserializeURI(const Maybe<URIParams>& aParams);
template <>
struct IPDLParamTraits<nsIURI*> {
static void Write(IPC::Message* aMsg, IProtocol* aActor, nsIURI* aParam) {
Maybe<URIParams> params;
SerializeURI(aParam, params);
WriteIPDLParam(aMsg, aActor, params);
}
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 23:45:22 +03:00
static bool Read(const IPC::Message* aMsg, PickleIterator* aIter,
IProtocol* aActor, RefPtr<nsIURI>* aResult) {
Maybe<URIParams> params;
if (!ReadIPDLParam(aMsg, aIter, aActor, &params)) {
return false;
}
*aResult = DeserializeURI(params);
return true;
}
};
} // namespace ipc
} // namespace mozilla
#endif // mozilla_ipc_URIUtils_h