-
-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request interceptors should be able to access the expected final URL #4793
Comments
Yeah I am facing the same issue. Would be great if those functions can be exported or somehow accessible without reaching deep into library implementation |
This is preventing me from supporting Axios 1.x in https://github.com/jamesmbourne/aws4-axios/ as the AWSv4 signature relies on the final URL. In previous versions I bolted together I understand the reason for this in not wanting to have any internal change result in a breaking change, but knowing what the final URL Axios is going to make a request to is crucial. |
@DigitalBrainJS perhaps a duplicate of #5000? |
any updates on this? |
Is your feature request related to a problem? Please describe.
An interceptor cannot be used for request signing purposes because it cannot access the final URL. Generating the final URL yourself involves duplicate logic to interpret the
baseURL
andparams
, which is risky and a maintenance burden.A workaround exists, but relies on "deep imports" which creates an expectation of stability for submodules of Axios that is probably not valid.
Describe the solution you'd like
Export a
buildURL
method from axios, so that it is possible to callaxios.buildURL(config)
to predict what the final URL will be using the same mechanisms Axios uses internally. This method would take all appropriate config parameters into account, i.e.baseURL
andparams
, unlike the internalbuildURL
helper which only really deals withparams
.Describe alternatives you've considered
This hack works, but it's probably not stable for the long term:
I'm guessing you'd prefer folks not rely on that, as
lib/helpers
andlib/core
are not part of the official API of Axios.Additional context
See also #1549. On that ticket it was suggested that a custom adapter was the way to go, but looking at the source for the core adapters, they depend on importing the same private, undocumented APIs I'm using above so I don't see how this helps.
Thanks for all your work on Axios. It is appreciated.
The text was updated successfully, but these errors were encountered: