compose-webview-multiplatform: additionalHeaders not working as expected

The doc of rememberWebViewState states:

param additionalHttpHeaders Optional, additional HTTP headers that are passed to [AccompanistWebView.loadUrl]. Note that these headers are used for all subsequent requests of the WebView.

It seems the bolded part isn’t actually true. The headers are passed along via the initial WebContent.Url object, but discarded when navigating inside the webview or using navigator.loadUrl().

I tried it by attaching an Authorization header to a request; the initial request worked, subsequent requests were rejected.

I can see a few options here:

  1. Change the docs and use the headers only for the initial request. But that would leave us with no option to actually provide universal headers.
  2. Keep the headers and apply them to every subsequent navigator.loadUrl() call. That would apply the headers to all requests created via the navigator, but not to requests created by the webview itself.
  3. Apply these headers to all requests. That’s probably a bit more work, on Android it would involve overrideUrlLoading, on Cef I don’t know.

My personal, related issue: I want to attach an Authorization header to all requests (if possible, only requests to a certain domain). I think at the moment this is impossible.


Tested using 1.6.0 and Android, but I think the current master works the same (except that additionalHeaders don’t work for desktop at all in 1.6.0).

Thanks for stepping up to build and maintain an KMP webview! 💪

About this issue

  • Original URL
  • State: open
  • Created 8 months ago
  • Comments: 17 (12 by maintainers)

Most upvoted comments

Hey, thanks for tackling this @KevinnZou! I have a half-finished implementation as well, and I got stuck on the desktop implementation too. So that strengthens @DatL4g’s point of moving it into KCEF if possible. Unfortunately I think I’m a little out of my depth there 😃

I pushed my implementation into a PR for inspiration. (Warning: nothing is finished in there!)

I have had more luck with overriding onBeforeResourceLoad and discovered that modifying CefRequests works fine. But cancelling a request breaks the implementation. So it’s probably a dead end too.

Besides, I’ve discovered a few more problems:

  • My initial intent was to be able to set the Authorization-header for particular websites. This works on Android, but CEF actually filters out the Authorization header (and probably a few others) if you try to set it via setHeaderMap(). So this isn’t a multiplatform solution, and authorization management would have to be a separate feature…
  • Different platforms have very different scenarios in which they trigger the request interception. On Android, shouldOverrideUrlLoading is only called for a few URLs but on CEF onBeforeResourceLoad is called for literally everything: images, css-files, etc. On iOS decidePolicyForNavigationAction probably has its own rules. So it’s tough to find common grounds so it works well on every platform without huge differences in behavior. (For example, in my implementation I tried to exclude non-mainframe requests for CEF)

The only thing I am happy about is the RequestInterceptor and how it is used. I think it is a good interface for users to work with.

On a side note, (K)CEF provides a CEFRequestHandlerAdapter that has default-implementations for all methods, meaning you don’t have to do that yourself

Adding a CefRequestHandler means overriding the default CefRequestHandler.

We had that problem before (user-agent) and we (or I) have to reimplement the default behavior in and make setting a CefRequestHandler extend the default reimplementation instead of overriding.

Additionally this doesn’t only break the ``onBeforeBrowse` implementation, it breaks all request handling methods.

I don’t have that much time currently as I’m in a release phase right now, best would be to add it directly to KCEF so we don’t have to deal with it in this library, maybe you could add a PR if you have time or we have to wait until I have time again (could be anytime in December).

I agree with you. I think RequestInterceptor is a great idea and I would go with this plan.