Lambdas in node 18.x (18.20.3) and problems with axios HPE_INVALID_HEADER_TOKEN

[josero25]

Version

18.20.3

Platform

No response

Subsystem

No response

What steps will reproduce the bug?

Hello everyone

Recently my newly deployed lambdas projects have started having problems with axios.

To give context, I had some lambdas in node, the last time they were deployed it was in LTS node 18.20.1, this week the lambdas have been redeployed, some without adulterating the logic and the axios calls that previously worked now throw the error " HPE_INVALID_HEADER_TOKEN", "Parse Error: Unexpected whitespace after header value."

It should be noted that the lambda that makes the call, as well as the one that returns the response, have not modified their behavior, the only thing that coincides is the launch of node 18.20.3 LTS a few days ago.

Initially using axios 1.6.8 and 1.7.1, tested with the latest version 1.7.2 and gives the same error.

Have you experienced something familiar or have some idea how to solve it, because setting the --insecure-http-parser flag makes it work, but it is not a viable option for me.

The headers were validated and do not contain white spaces at the beginning, at the end, or after the comma.

How often does it reproduce? Is there a required condition?

Whenever a request is made with axios

What is the expected behavior? Why is that the expected behavior?

Get a 200 response

What do you see instead?

HPE_INVALID_HEADER_TOKEN error, Parsing error: Unexpected whitespace after header value

Additional information

We are aware that the problem has occurred in lambdas deployed since Friday, May 25, but we cannot establish a start date for the problem.

[marco-ippolito]

I believe there might have been an llhttp update (Probably https://nodejs.org/en/blog/vulnerability/april-2024-security-releases) and you are parsing invalid http.
Can you provide a sample of the http string you receive?
Also a quick test is to enable insecureHTTPParser and see if it doesnt throw

cc @ShogunPanda

[josero25]

Hello, this is an example of the headers received in that HTTP request.

"content-type" : "application/json",
"content-length": "462",
"connection": "close",
"date": "Tue, 28 May 2024 19:43:16 GMT",
"strict-transport-security": "max-age=63072000; includeSubDomains; preload",
"x-amz-apigw-id": "WD0FGENyoAMEnzg=",
"x-requested-with": "*",
"x-amzn-trace-id": "Root=1-645567d9-7047217d3ac9156c5c48ee92",
"via": "1.1 99baesabf4b5bb562478dafe56734245cc.cloudfront.net (CloudFront), 1.1 457d8c6fbd4356ae7a8f93e7446fc81e.cloudfront.net (CloudFront)",
"referrer-policy": "same-origin",
"content-security-policy": "default-src 'self' *.company.com; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests;",
"x-content-type-options": "nosniff",
"pragma": "no-cache",
"permissions-policy": "camera=(), geolocation=()",
"upgrade-insecure-requests": "1",
"vary": "Origin",
"x-amzn-requestid": "1acefade-6a2a-72c1-9d42-1c5d12fa71af",
"x-amz-cf-pop": "IEA67-A6, IEA23-P6",
"x-cache": "Miss from cloudfront",
"x-amz-cf-id": "pcpF_wA1TDaVeFs0Q_rwAxRGEiertu_fcGw0w0e4D1g0aiFAvaefAd==",
"set-cookie": "visid_incap_3245641=Xae3Vfa6D21ArW9Qd4WsQEJxBJIBBBBBESARBBBBBBAEXWagxdfqtwaqwerEs341; expires=Wed, 28 May 2025 06:46:21 GMT; HttpOnly; path=/; Domain=.company.com; Secure; SameSite=None, nlbi_3245641=+vuMNqF4w3rFH5vgAVQWYrBBBBCXnqDBFa6nqagnij+wA3DX; path=/; Domain=.company.com; Secure; SameSite=None, incap_ses_347_2671235=Df/2d7NWdasyCP3ehI4qVXNrTmNBBBBBaUDnP+5r4taxcvMOVAVGuf==; path=/; Domain=.company.com; Secure; SameSite=None",
"x-cdn": "Imperva Access-Control-Allow-Origin: api.company.com, *.company.com, api.company.com",
"accept": "application/json",
"x-iinfo": "6-56725457-23573525 MMMM DH(0 4 0) RT(5634752382631 3) q(0 0 0 -1) r(0 1) U36"

Using the insecureHTTPParser all requests pass fine.