Issue 1:
Summary

When transforming response data via AxiosRequestConfig.transformResponse, there is no way to drive transformation logic differently depending on the HTTP status of the response.

This is a problem for me because I want to implement a transform that transforms only successful responses. Successful responses (in 200 range) are guaranteed to contain data in a well-defined format that I want to transform, but unsuccessful responses may contain a variety of response data structures (dependent on the type of error) that I want to pass-through my transform without modification so that they can be later processed by a more generic error response handler.

Implementing my transform to detect what type of structure is in the response based on the response data alone is impractical. The API I am working with clearly defines the structure of the response for each HTTP status code it may respond with, so there's no reason that I should have to reverse-engineer what kind of response it is by inspecting the response data (and it may not even be possible to do so unambiguously).

Some options:

Pass HTTP status code to AxiosRequestConfig.transformResponse (most useful option IMO)

Pros:

Allows for granularity of transforming data differently based on status code.

Cons:

Requires duplicating logic to decide whether response code is success vs error if that's all you care about (maybe this could be solved by also passing a "success" boolean?).

Introduces a difference in signature for transformResponse vs transformRequest, which may complicate some of the existing design/code that essentially treats them both the same.

Add 2 new options to AxiosRequestConfig:

transformSuccessResponse: transforms response data ONLY for success responses

transformErrorResponse: transforms response data ONLY for error responses.

Pros:

Makes use of existing determination of which status codes are considered success vs error.

Cons:

Missing granularity for converting different response data structures for different error status codes.

Requires backward compatibility for continuing to use transformResponse for all responses.

Context

axios version: e.g.: v0.17.1

Environment: *e.g.: irrelevant

Issue 2:
Summary

Recently #1323 has been fixed, however follow-redirects is still not correctly implemented: current version does not handle errors correctly.

Indeed, if maxBodyLength is 10MB and the resource fetched after the redirect is bigger, follow-redirects will emit an error but that error will occur outside of axios promise chain.

Error: Request body larger than maxBodyLength limit
at RedirectableRequest.write (./node_modules/follow-redirects/index.js:66:24)
at FormData.CombinedStream.write (./node_modules/combined-stream/lib/combined_stream.js:118:8)
at FormData.CombinedStream._pipeNext (./node_modules/combined-stream/lib/combined_stream.js:106:8)
at FormData.CombinedStream._getNext (./node_modules/combined-stream/lib/combined_stream.js:79:10)
at FormData.CombinedStream._pipeNext (./node_modules/combined-stream/lib/combined_stream.js:107:8)
at FormData.CombinedStream._getNext (./node_modules/combined-stream/lib/combined_stream.js:79:10)
at FormData.CombinedStream.resume (./node_modules/combined-stream/lib/combined_stream.js:134:10)
at FormData.CombinedStream.pipe (./node_modules/combined-stream/lib/combined_stream.js:64:8)
at dispatchHttpRequest (./node_modules/axios/lib/adapters/http.js:227:12)
at httpAdapter (./node_modules/axios/lib/adapters/http.js:18:10)
at dispatchRequest (./node_modules/axios/lib/core/dispatchRequest.js:59:10)

Axios should intercept that error and reject the promise

Context

axios version: v0.17.1 + master

Environment: node v8.4.0