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.

/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to