PSA: Upcoming changes to the creation of Necko channels

Ehsan Akhgari 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 [1] a network fetch is being performed
>> for.
>>
>> 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: 
<https://dxr.mozilla.org/mozilla-central/source/dom/fetch/InternalRequest.h#34>

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 mailing list