According to https://github.com/axios/axios#semver, Axios follows semver.

My understanding of this change is that the setHeader() function started throwing an error now, which it didn't before, and that this is generally considered a breaking change.

I noticed this in mdn/mdn-http-observatory#489, because our tests failed. For our use case in the MDN HTTP Observatory, we would prefer if setHeader() didn't throw, or if there was an opt-out mechanism.

Thanks, @caugner. I should have checked more cases, as I had determined this to be quite low risk for 99% of users. I will add an explicit opt-out and make a PR to the MDN lib as soon as it is ready.

Thanks. I'm wondering how other HTTP request frameworks handle invalid headers. Do they throw, or do they ignore or sanitize the value instead?

I don't actually know. I will do some research. Would it be fine in your case if this is just sanitised and does not throw? That would be a better approach for us. In the past, security opt-in has led to the same CVEs being opened repeatedly.

Would it be an option to have two modes for handling \r and \n in headers:

• loose (default) replaces them with space, and
• strict (opt-in) throws an error.

You could then make strict the default option in Axios v2.

Sure, that can work! Thanks for the suggestion. I will do that asap.

RFC 9110 defines the grammar of HTTP field values as follows:

  field-value    = *field-content
  field-content  = field-vchar
                   [ 1*( SP / HTAB / field-vchar ) field-vchar ]
  field-vchar    = VCHAR / obs-text
  obs-text       = %x80-FF

(VCHAR is defined in RFC 5234)

So strictly speaking the isValidHeaderValue() function is not complete, and could be something like this:

const isValidHeaderValue = (value) =>
  // HTAB:    \x09 (not allowed as first/last character)
  // SP:      \x20 (not allowed as first/last character)
  // VCHAR:   \x20-\x7E
  // obs-text \x80-\xFF
  /^[\x09\x20-\x7E\x80-\xFF]+$/.test(value) && !/^[\x09\x20]|[\x09\x20]$/.test(value);

Edit: Loose mode could strip forbidden characters.

const sanitizeHeaderValue = (value) =>
  value
    .replace(/[^\x09\x20-\x7E\x80-\xFF]/g, '')
    .replace(/^[\x09\x20]|[\x09\x20]$/g, '');

Thanks @caugner, this is very helpful. I will implement as soon as I have a gap and do a release. May bundle some more fixes with this, but I do quite like just doing the "Loose mode" as this is a better solution.

If your application relied on including raw line breaks in headers then it was broken before. Asking for a major version bump just to make this throw an error this is kind of strange... There's simply no valid reason to include a line break when setting a header.

Fix included in release 4.14.0-0.nightly-2026-04-22-065932

Fix included in release 4.15.0-0.nightly-2026-04-22-170323