Or apparently http-on-modify-request observers won't be happy.

I don't *think* this is a big deal for now. Certainly for some extensions, and in our tree: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/content/xml-fetcher.js#174 (presumably so we don't send cookies with urlclassifier requests) http://mxr.mozilla.org/mozilla-central/source/extensions/metrics/src/nsMetricsService.cpp#926 Neither of those look like fennec blockers to me. I think we'd want to fix this by rejigging AsyncOpen to work like this: Child AsyncOpen: - serialize URIs, inparams etc - SendAsyncOpen to parent Parent AsyncOpen: - build headers, add cookies - call OMR for parent-side observers - SendOMR to the child Child RecvOMR: - call OMR for child-side observers - SendOMRDone to parent Parent RecvOMRDone: - update headers if changed - actually open the channel This involves an extra IPC roundtrip. This *could* be optimized away in the common case (?) of no child-side OMR observers. (Querying the observerservice for that info is trivial.) RESO/LATER.

This has already been fixed by other patches.