On 2015-04-03 11:21 AM, Jonas Sicking wrote:
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari <ehsan.akhg...@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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
