Replies: 1 comment
-
I agree with this. Even if we didn't specify a new instance, exporting the axios instance used by inertia would be useful. I actually made reference this issue in another discussion here. A key issue for me is that each router.visit/reload request creates a new Axios object into memory with no ability to override or even access this instance at runtime. This is fundamentally broken IMO. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While testing a Capacitor wrapped Inertia Vue 3 app on Android, I have noticed that while the XHR requests performed using a custom axios instance were fine, the ones done by Inertia's router had their responses' headers rewritten (x-inertia header gone, content type changed to text/html, a client-via header added with the value shouldInterceptRequest.
Apparently, this happens because Inertia uses the same domain for the initial HTML request, as well as the subsequent XHR requests and the app domain is whitelisted, to allow proper in-app navigation (server.allowNavigation, in capacitor.config.json).
I don't know exactly why a custom axios instance behaves ok - probably Capacitor or Android's webview only alters the default axios instance.
I manage to solve this with the following code in boostrap.js, for those with the same issue (haven't found this online):
Seems that were I able to specify that router would use a custom axios instance, everything would have worked without the interceptor.
On web and on iOS, everything works fine; only Android has this issue.
Beta Was this translation helpful? Give feedback.
All reactions