On 7/18/18 5:18 PM, Botond Ballo wrote:
My reading of the proposal is that that's an extension mechanism for
the program to be able to override handling of standard URI schemes,
or invent new ones (such as for serving a page from a string in the
C++ program's memory), but if e.g. the program does not override the
"http" URI scheme, the OS-provided implementation's default handler
(including the network stack) would be used.

I'm glad we're having this conversation, because that was not obvious to me.

If the intent is that the default behavior is to speak http, what are the committee's thoughts on things like sandboxing, spectre mitigations, process-per-origin, etc?

This last is particularly concerning in terms of API surface, because interfacing with a multiprocess embedded browser might be quite different from interfacing with a single-process one...

dev-platform mailing list

Reply via email to