PSA: Upcoming changes to the creation of Necko channels
ehsan.akhgari at gmail.com
Mon Apr 6 17:21:21 UTC 2015
On 2015-04-03 11:21 AM, Jonas Sicking wrote:
> On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com> wrote:
>> Next week, I'm planning to land the patches to bug 1149853 which enables
>> Gecko to track which RequestContext  a network fetch is being performed
>> This will enable us to correctly signal the context for which a given
>> request was made to service workers that intercept the corrresponding
>> network connection.
>> This requires modifying the C++ and JS APIs for creating Necko channels.
>> The changes to the callers is straightforward, you pass the value that
>> describes the kind of network request you're making (for example, whether
>> it's being used for an image, a stylesheet, or loading an iframe, etc.) in
>> the form of a member of the mozilla::dom::RequestContext enum, or a string
>> from the WebIDL enum. Note that for the network connections that are used
>> for our own purposes which do not belong to a specific web page, this value
>> won't be used, so its value doesn't matter in practice, but as convention,
>> please pass RequestContext::Internal/"internal".
>> (Note to comm-central maintainers: unfortunately I won't have the time to
>> look into the comm-central consumers for this one, since the fixes
>> especially to JS code will require manual testing, it would be great if you
>> can start with applying my patches on mozilla/ and update the comm-central
>> consumers. For comm-central, you can always use the "internal" value.)
> We've recently done work to make all code which create necko channels
> pass in a nsIContentPolicy type. This maps very closely to request
> context types. Would be good if we could leverage the work already
> done and also avoid having to pass in two types.
The issue is that I can't think of a clean mapping between the two
pieces of information. Here is an example: RequestContext includes
different values for "iframe" and "metarefresh". From the content
policy side of things, we probably want to treat the loads for documents
inside an iframe as TYPE_SUBDOCUMENT no matter whether the load comes
from a <meta http-equiv=refresh> or some other source, however,
depending on what the conclusion of
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=28361> ends up being, we
may use the "metarefresh" context for such loads, which loses the
information about the fact that the load is happening inside an iframe.
Also, we have a few content policy types that all map to "internal"
value of the RequestContext enum (such as TYPE_XBL, TYPE_OTHER and
TYPE_DOCUMENT.) I have tried to document some of this mapping in this
table which may help demonstrate the issue better:
Based on this many-to-many mapping, I can't think of a clean way to
avoid passing both values at the call site.
More information about the tb-planning