Skip to content
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

Download continues after maxContentLength exceeded #1098


Copy link

@nornagon nornagon commented Sep 22, 2017

#### Summary

The following code demonstrates the issue:

  { maxContentLength: 2000 }
  .then(d => console.log('done'))
  .catch(e => console.log(e.toString()))

Expected behavior:

  • The script exits immediately after printing "Error: maxContentLength size of 2000 exceeded"
  • Not much more than 2KB was downloaded from the server

Actual behavior:

  • The script prints "Error: maxContentLength size of 2000 exceeded", then continues to download the remaining 52MB of data from the server. It takes about two minutes before it exits on my connection.

It's possible to work around this by adding a cancellation token and manually canceling the request when an error is encountered. However, since the request never actually fires a "complete" event, it's surprising that the download continues, only to have the data be thrown into the void.

#### Context

  • axios version: v0.16.2
  • Environment: node v8.4.0, macOS Sierra 10.12.6

This comment has been minimized.

Copy link

@eauc eauc commented Oct 6, 2017


Same problem here. I looked into the code of lib/adapters/http.js, and I made some tests.
Maybe we could just close the response stream when the maxContentLenght is reached ?


if (config.maxContentLength > -1 && Buffer.concat(responseBuffer).length > config.maxContentLength) {
  + stream.destroy();
  reject(createError('maxContentLength size of ' + config.maxContentLength + ' exceeded',
              config, null, lastRequest));

This simple modification works in my tests, the rest of the reponse body is not fully loaded into memory anymore.

Another way to obtain this behavior is to destroy the response stream in the catch handler in the client code:

  url: ...,
  maxContentLength: 2000,
}).catch((error) => {

This is an acceptable solution for me, don't know if you want to make this behavior the default ? (I think it would me more sensible).

At least we could add this method in the documentation ?

Thanks in advance.


This comment has been minimized.

Copy link

@josh-keating josh-keating commented Apr 23, 2019

What's the likelihood of this PR getting approved / merged?

Sourceclear is raising this as a vulnerability, with this PR being the fix:


This comment has been minimized.

Copy link

@CesarGomezTissini CesarGomezTissini commented May 30, 2019

It is getting a high severity security hole now from GitHub, what is going on?
dependanbot shows continually there isn't a single fix for that.

cjduncana added a commit to cjduncana/decoder-js that referenced this issue May 30, 2019
Given the open issue axios/axios#1098, I decided to remove axios from
the example project.

This comment has been minimized.

Copy link

@heisian heisian commented May 30, 2019

I'm pretty sure the maintainers are AWOL.


This comment has been minimized.

Copy link

@Sequoia Sequoia commented May 30, 2019

Does this impact Axios in browser or just server?


This comment has been minimized.

Copy link

@Coder2012 Coder2012 commented May 30, 2019

As mentioned on the Snyk blog

If you are requesting resources from untrusted sources, or via insecure mediums, then you are potentially vulnerable to Denial of Service where malicious users can control the remote resource.

When using axios in a Node.js server this can be disastrous due to the single threaded nature of the runtime. A spike in resources such as I/O and CPU negatively affect all users connected to that server. In browser environments, the Denial of Service negatively affects end-users with varying severity, depending on how the resource fetching with axios is used in the application.

emilyemorehouse added a commit that referenced this issue May 30, 2019

This comment has been minimized.

Copy link

@anulman anulman commented May 30, 2019

Fix is released as part of 0.19.0; per @emilyemorehouse's comment there should be a more targeted 0.18.1 release made available as well shortly.

Let's all thank the maintainers and contributors for their generous work <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
8 participants
You can’t perform that action at this time.