This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm sifting through Blink's innards to align what requests types we use with what the spec says we should care about. There are some differences; we should resolve them. Currently, Blink/Chromium use two different enums for different purposes (historical artifact from WebKit days; Chromium and Safari had different needs): Resource::Type: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/fetch/Resource.h&l=61 ResourceRequest::TargetType: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/network/ResourceRequest.h&l=55 Most of these map nicely to one of the request contexts defined in Fetch. Some don't. Specifically, I'm looking at: * `Resource::LinkSubresource`/`ResourceRequest::TargetIsSubresource` (which we use to set download priorities of things like `<link rel="subresource">`, distinct from `<link rel="prefetch">`. * `Resource::Raw` which, among other things, carries requests from PPAPI plugins like Flash. * `Resource::TextTrack`: I think we can fold this into `Resource::Media`, but it looks like there's some special-casing of behavior in Chromium that's not done yet, so I'm not sure why it's there. :) * `Resource::Favicon`: Again, this sets priority, and tells Chromium to set some flags which ignore login requests. On the one hand, I want as much detail as possible so I can granularly turn off mixed content for specific types as usage data allows. On the other, I don't want Fetch to have to know about EVERYTHING EVER OMG. Where do you think the balance lies?
* `Request::ImportResource` for HTML Imports, which Blink currently blocks as active content. I suppose we could map this to the 'script' context?
I am totally fine with adding more contexts and having all the granularity forever. Contexts are very cheap and it's good to have an overview of what kind of fetching is out there. I'm not sure how I feel about contexts being responsible for setting other bits on the request field. E.g. if you care about authentication you need to set the "authentication flag" (by default unset as the whole prompting thing there is bad UI). Now on the other hand I have been thinking about contexts being responsible for setting headers in http://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch (e.g. setting Accept to a particular value) so maybe that is not such a bad idea?
For the moment, I think I'd suggest something like the following: * Rename `navigate` to `mainFrame` (are there any other types of navigation?) * Rename `child` to `childFrame` (since you've already split workers out) * Split `media` into `audio`, `video`, and `textTrack`. * Add `favicon`. * Add `subresource`. * Add `objectRequest` (as distinct from `object`). But let's keep this open while I'm working on the refactoring patches. It's not yet clear to me which of the request types are purely historical, and which have actual impact on the way the Blink or Chromium's network stack makes requests.
Do you happen to know the right folks to poke on Mozilla's side? It'd be nice if we aligned our expectations regarding what's actually needed for UAs to do the things they're currently doing.
toplevelbrowsingcontext and browsingcontext would be better. Although maybe we should use topframe and frame given that CSP has frame-ancestor as term already? topdocument / document could also work. What is objectRequest?
(In reply to Anne from comment #5) > toplevelbrowsingcontext and browsingcontext would be better. Although maybe > we should use topframe and frame given that CSP has frame-ancestor as term > already? topdocument / document could also work. Up to you, I don't really care how we spell bikeshed. :) > What is objectRequest? Requests made by plugins (which we sometimes see in Chromium/Blink, and sometimes don't: hooray for plugins).
https://groups.google.com/d/msg/mozilla.dev.platform/4Cfqd1yLkjY/8L8FOuatB7EJ re asking others at Mozilla. Re plugins, makes sense. Not sure about the name, might bikeshed. What about <object>? We don't really know whether it ends up creating a browsing context or will just display an image before we get the response. It causes problems for service workers as well (should this request be associated with a new service worker or the current one, in particular).
(In reply to Anne from comment #7) > What about <object>? We don't really know whether it ends up creating a > browsing context or will just display an image before we get the response. > It causes problems for service workers as well (should this request be > associated with a new service worker or the current one, in particular). We "solve" that in CSP by not caring: if it's loaded via `<object>`, it's controlled by 'object-src', regardless of what it turns out to be.
Per the thread linked in comment 7 it seems we need to add these to the list from comment 3: * xslt (<?xsl-stylesheet?> I presume and perhaps the JavaScript API?) * cspreport Should we have separate contexts for <a ping> and sendBeacon()?
(In reply to Anne from comment #9) > * xslt (<?xsl-stylesheet?> I presume and perhaps the JavaScript API?) Chromium folds this into `style`, but adding granularity is fine. > * cspreport Chromium folds this into `ping`, but adding granularity is fine. > Should we have separate contexts for <a ping> and sendBeacon()? If you'd like to be totally granular, sure. If we're going that route, we should split `connect` into `xhr`, `eventsource`, and `websocket`.
I'm not really sure what I want yet :-) But given that XSLT can execute script, it should probably not be style.
(In reply to Anne from comment #11) > I'm not really sure what I want yet :-) But given that XSLT can execute > script, it should probably not be style. Sorry, you're entirely correct. I wrote 'style' but I meant 'script'.
(In reply to Anne from comment #11) > I'm not really sure what I want yet :-) The more I think about it, the more I'd suggest erring on the side of too much detail. If we're going to have a list of request types, then we ought to be sure it's exhaustive.
I fixed this bug I think except for the websocket suggestion. Maybe there's something I don't understand about WebSocket, but this is the second time someone suggested it should be grouped into Fetch, whereas I think it's mostly its own platform. (Except for grabbing the cookies somehow.) If you think it should be covered here rather than by WebSocket directly, please file a new bug. https://github.com/whatwg/fetch/commit/3ce8a2131e8cfa75446e5d24b682413039394f34 Commit summary follows. I ended up adding these: * subresource * plugin (::Raw) * track (::TextTrack) * audio * video * favicon * eventsource * xmlhttprequest * fetch And removing: * connect * media Per feedback from comment 7 from Mozilla I added: * beacon * cspreport * xslt Per feedback from https://github.com/slightlyoff/ServiceWorker/issues/352 I added a new field "context frame type" as well as these contexts: * hyperlink * frame * iframe * embed * location And removed these as a result of that GitHub thread: * child * navigate * popup
A few things I've seen while poking at Blink: 1. Navigations (and potentially requests) can happen based on user input to the UA, rather than clicking a link (back button, reload button, etc). I don't know how these are modeled in Gecko, but in Blink, they show up as Fetches (which are resolved by the cache). 2. Requests from devtools, and other "internal" bits and pieces pass through the fetching mechanisms in Blink. Based on this, I'd suggest adding an "internal" request type. Happy to throw that in a separate bug if that makes more sense. Otherwise I'd just reopen this one. Also: I'm finding a lot of Blink code that relied on conflating the initiator of a request ("hyperlink") and the target of the request ("iframe" vs "main"). Adding a context frame type will help clear this up. Thanks for that.
And HTML Imports. I'm throwing those into 'script' for the moment (which might be reasonable in general?).
https://github.com/whatwg/fetch/commit/2cc41cf2d0872bc87a849e1faaa7cec1633aea39 Let's do new bugs for any new things that come up. Thanks for all the help so far!