Igalia<\/a> and Protocol Labs<\/a> has been collaborating for some years already to improve the multi-protocol<\/strong> capabilities in the main browsers; most of our work has been done in Chrome, but we have interesting contributions in Firefox and of course we have plans to increase or activity in Safari.<\/p>\n As I said in the mentioned post, one of the long-term goals that Protocol Labs has with this work is to improve the integration of the IPFS<\/em> protocol in the main browsers. On this regard, its undeniable that the Brave<\/strong> browser is the one leading this effort<\/a>, providing a native implementation of the IPFS<\/em> protocol that can work with both, a local IPFS<\/em> node and the HTTPS<\/em> gateway. For the rest of the browsers, Protocol Labs would like to at least implement the HTTPS gateway<\/em> support, as an intermediate step<\/strong> and to increase the adoption and use of the protocol.<\/p>\n This is where the Chrome’s pre-defined custom handlers<\/strong> feature could provide us a possible approach. This feature allows Chrome to register handlers for specific schemes at compile-time. The ChromeOS<\/em> embedders use this mechanism to register handlers for the mailto<\/em> and webcal<\/em> schemes, to redirect the HTTP<\/em> requests to mail.google.com<\/em> and google.com\/calendar<\/em> sites respectively.<\/p>\n The idea would be that Chrome could use the same approach to register pre-defined handlers for the IPFS<\/em> scheme, redirecting the IPFS<\/em> request to the HTTPS gateways<\/em>.<\/p>\n In order to understand better how this feature would work, I\\’ll explain first how Chrome deals with the needs of the different embedders regarding the schemes.<\/p>\n The SchemeRegistry<\/em> data structure is used to declare the schemes registered in the browser and assign some specific properties to different subsets of such group of schemes.<\/p>\n The data structure defines different lists to provide these specific features to the schemes; the main and more basic list is perhaps the standard schemes<\/em>, which is defined as follows:<\/p>\n A standard-format scheme adheres to what RFC 3986 calls “generic URI syntax” (https:\/\/tools.ietf.org\/html\/rfc3986#section-3).<\/p><\/blockquote>\n There are other lists to lend specific properties to a well-defined set of schemes:<\/p>\n The following class diagram shows how the SchemeRegistry<\/em> data structure is defined, with some duplication to avoid layering violations, and its relationship with the Content Public API<\/em>, used by the Chrome embedders to define its own behavior for some schemes<\/p>\n It’s worth mentioning that this relationship between the \/\/url<\/em>, \/\/content<\/em> and \/\/blink<\/em> layers shows some margin to be improved, as it was noted down by Dimitry Gozman (one of the Content Public API owners) in one of the reviews<\/a> of the patches I’ve been working on. I hope we could propose some improvements on this code, as part of the goals that Igalia<\/a> and Protocol Labs<\/a> will define for 2023.<\/p>\n As it was commented on the preliminary discussions<\/a> I had as part of the analysis of the initial refactoring work described in the first section, Chrome already provides a way for embedders to define new schemes and even modifying the behavior of the ones already registered. This is done via the Content Public API<\/em>, as usual.<\/p>\n The Chrome’s Content Layer offers a Public API that embedders can implement to define its own behavior for certain features.<\/p><\/blockquote>\n One of these abstract features is the addition of new schemes to be handled internally. The ContentClient<\/em> interface has a method called AddAdditionalSchemes<\/em> precisely for this purpose. On the other hand, the ContentBrowserClient<\/em> interface provides the HasCustomSchemeHandler<\/em> and IsHandledURL<\/em> methods to allow embedders implement their specific behavior to handler such schemes.<\/p>\n The following class diagram shows how embedders implements the Content Client<\/em> interfaces to provide specific behavior to some schemes:<\/p>\n I’ve applied a refactoring<\/a> to allow defining pre-defined handlers via the SchemeRegistry<\/em>. This is some excerpt of such refactoring:<\/p>\n Finally, embedders would just need to implement the ChromeContentClient::AddAdditionalSchemes<\/strong> interface to register a scheme and its associated handler.<\/p>\n For instance, in order to install in Android a predefined handler for the IPFS<\/em> protocol, we would just need to add in the AwContentClient::AddAdditionalSchemes<\/em> function the following logic:<\/p>\n The pre-defined handlers allow us to introduce in the browser a custom behavior for specific schemes.<\/p>\n Unlike the registerProtocolHandler<\/em> method, we could bypass some if the restrictions<\/a> imposed by the HTML API<\/em>, given that in the context of an embedder browser its possible to have more control<\/strong> on the navigation use cases.<\/p>\n The custom handlers, either using the pre-defined handlers approach or the registerProtocolHandler<\/em> method, is not the ideal way of introducing multi-protocol<\/em> support in the browser. I personally consider it a promising intermediate step<\/strong>, but a more solid solution must be designed for these use cases of the browser.<\/p>\n","protected":false},"excerpt":{"rendered":" In a previous post I described some architectural changes I’ve applied in Chrome to move the Custom Handlers logic into a new component. One of the advantages of this new architecture is an easier extensibility for embedders and less friction with the \/\/chrome layer. Igalia and Protocol Labs has been collaborating for some years already … Continue reading Discovering Chrome’s pre-defined The SchemesRegistry<\/h2>\n
\/\/ Schemes that are allowed for referrers.\nstd::vector
![\"\"](\"https:\/\/notes.igalia.com\/uploads\/b92b1657-d4c7-43fc-9c8a-ac0c349f503b.svg\")
<\/p>\nAdditional schemes for Embedders<\/h2>\n
![\"\"](\"https:\/\/notes.igalia.com\/uploads\/aec833af-cc6e-49ba-820d-21b19791dfad.svg\")
<\/p>\n\/\/ Schemes with a predefined default custom handler.\nstd::map
\n schemes.predefined_handler_schemes.emplace_back(\n \"ipfs\", \"https:\/\/dweb.link\/ipfs\/?uri=%s\");\n schemes.predefined_handler_schemes.emplace_back(\n \"ipns\", \"https:\/\/dweb.link\/ipns\/?uri=%s\");\n<\/pre>\n
Conclusion<\/h2>\n
Custom Handlers<\/span><\/a><\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1756","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1756","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/comments?post=1756"}],"version-history":[{"count":83,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1756\/revisions"}],"predecessor-version":[{"id":1855,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1756\/revisions\/1855"}],"wp:attachment":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/media?parent=1756"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/categories?post=1756"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/tags?post=1756"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}