That’s ridiculous. I love axios and it’s my goto client in node but this breaking change hurts the ergonomics of the library.

This might be an oversight but in v1 we have been a lot stricter with our URL parsing. The URL is for your URL free of any query params. Thus we have params as part of the config.

If you use a URL like this http://test.example.com?test=1 we will be stripping out the ?. Please use the params to set query params.

Same here, we’re going to refactor but there is no mention of this in the breaking changes

No probs but credit goes to @DigitalBrainJS. Sorry for all the problems this caused. Please can anyone interested watch our releases as we need many more testers on pre-releases, I can only do so much.

had this same issue. reverting to 0.27.2 fixed it.

this is how a working call looks for me (v0.27.2):

this is what a broken call looks for me (v1.3.4) with no code changes, just upgrading the package:

Releaseing now

Came here from this StackOverflow question.

The docs still says that ? can be used in URL string, and using params config is optional.

To resolve the discrepancy, either the library can be updated to support query params in URL strings (like in v0), or the docs can be updated to match the current v1 behavior.

How about this?

Curl command for illustration only

For illustration … a curl command that returns with my personal GIT Access token a list of commits when searching the axios repo. As I said its just for illustration. If you want to execute the curl command you need to update the my_token value in the command.

Request:

curl -v -s -X GET -H "Accept: application/vnd.github.v3+json" -H "Authorization:token my_token" https://api.github.com/search/commits?q=sort:committer-date-desc+merge:false+repo:axios/axios&per_page=50&page=1

Response looks normal as I get a list of commits.

Axios v1.0.0-alpha.1

Steps/Run

• rm -rf node_modules
• npm install axios@v1.0.0-alpha.1
• vi test.js
• copy/paste this into test.js

const axios = require('axios');

const config = {
    headers: {
        Authorization: 'token my_token',
        Accept: 'application/vnd.github.v3+json'
    }
}

axios.get('https://api.github.com/search/commits?q=sort:committer-date-desc+merge:false+repo:axios/axios&per_page=50&page=1', config).then(function (response) {
    // handle success
    console.log(response);
})
    .catch(function (error) {
        // handle error
        console.log(error);
    })

• Update my_token with your GIT Access token in above code and save.
• node test.js

Response looks normal as I get an array of commits back.

Axios v1.0.0

Steps/Run

• rm -rf node_modules
• npm install axios
• use same test.js as above
• node test.js

Response

AxiosError: Request failed with status code 404
...
...
...
  data: {
      message: 'Not Found',
      documentation_url: 'https://docs.github.com/rest'
    }

Thx for fixing @jasonsaayman 👍

Sorry about that, something that I should have picked up, I will try to be a bit more strict on changes which are to largely incompatible.

Fixed with #5018

I can confirm this error as well after upgrading to v1.0.

Simple scripts are failing, so I had to roll back to v0.27.2.

Hope it’s some simple issue which can easily be fixed.

Thanks for working on the project!

+1

+1

I can also confirm these errors as lots of our get requests are failing now and we had to rollback.

For those wondering, or too lazy to refactor everything, or using Axios to fetch full URLs they don’t manage (our use case: we fetch a RSS feed containing links to items and the item URL might contain query params, it’s an opaque string for us) I resorted to using this interceptor:

instance.interceptors.request.use((req) => {
  const url = new URL(axios.getUri(req)), // getUri will build the final URI, merging defaults
        params = new URLSearchParams(url.searchParams);

  url.search = '';

  req.url = url.href; // The URL without query params
  req.params = params; // The merged query params from defaults + request

  return req;
});

In my context, I’m paying the extra CPU cycles for the useless interceptor. I’m hoping for Axios to reintroduce previous behavior

Path including Query String is considered URL (URI) in HTTP semantics

https://www.rfc-editor.org/rfc/rfc9110.html https://www.rfc-editor.org/rfc/rfc3986.html#page-16

This changes break any application that accept URL as user input and pass directly as URL to axios.get(), post() and others. Axios should support URL scheme according to HTTP semantics to conform with specifications and better user experience.

In case user supply query_params it should append to URL with & or ? as neccessary.

@jasonsaayman @mzabriskie @nickuraltsev It’s clear now that this goes beyond a simple whoopsie 😅

Do you agree on fixing this? If so, I’m willing to work on a PR if this is of any help.

Cheers, David

Same here. Tests are broken on v1.0.0 (node 16) because query parameters are no longer working.

Since most APIs, including nodejs include the search parameters in the URL object, this change is miss-leading in my opinion. Especially since there is no warning in the readme about it.

Also, it is very strange to remove the ? character but not the actual parameters behind it if the url configuration param actually contains a query string… this is asking for trouble, I think.

Clearly, this is a bug in Axios. new URL(…) has no problem parsing query params:

new URL('https://api.example.com/path?bug=axios')
URL {
  href: 'https://api.example.com/path?bug=axios',
  origin: 'https://api.example.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'api.example.com',
  hostname: 'api.example.com',
  port: '',
  pathname: '/path',
  search: '?bug=axios',
  searchParams: URLSearchParams { 'bug' => 'axios' },
  hash: ''
}

@jasonsaayman seems like PR #4852 should be reverted for now. Axios should definitely be able to parse params from a query string. Currently, these changes do more harm than good, since the problem they solve is not critical, but only potentially possible and has existed for years. This should be carefully considered from all points of view before such incompatibilities are introduced. Another, more thoughtful solution should be found.

Please use the params to set query params.

I have the same problem as the original poster.

Does this mean that, to send a request to an URL from elsewhere that may contain a query string, I have to detect the question mark, split the URL manually and put the querystring into the params? This probably also means that I should be using URLSearchParams to avoid writing a querystring parser myself, right?