Repository navigation
Make HTTP_MAX_HEADER_SIZE configurable #24692
Description
Activity
Major +1 here. Our large enterprise is not in the position to reduce the possible headers that flow through our infrastructure to 8k. Agree that patching node at compile time is not a good solution for us.
Reacted by Trey Philips, Patrick Ritchie, Nathan Chapman, Boris Bera, Marcin Pawelek, Scott Rossillo, Steve Mason, Bryce Steinhoff, GP, Matthew West and 14 moreWe are running into the same issue. The drop from 80kb to 8kb is forcing us to stick with the previous version of node until this is resolved.
This needs to be configurable either through a command line option, environment variable, or in code. A compile time flag is not a good solution for us (or probably 99% of other devs) either.
Reacted by Valentin Hervieu, Trevor Toryk, ptaunton, Steve Mason, Scott Rossillo, Bryce Steinhoff, Rémy Bach, Matthew West, Michael McLafferty, James and 17 moreSorry if I missed the conversation somewhere, but do we have the option of updating
http_parser(or floating a patch on it) to make the max header size configurable at the parser level?I did a little experimenting (definitely not PR ready at this point) at cjihrig@e55765d, and was able to adjust the max header size. It breaks ABI, but I'm not sure if we worry about that with the http parser.
cc: @bnoordhuis
EDIT: I don't think I would attach the max header size to the parser, but maybe add a function that sets the global max header size. That shouldn't break ABI. (cjihrig@fb615c5)
It's also a major issue that this went out as a patch level fix to LTS editions. This is a breaking change.
Ideally this 8K hard limit commit should be reverted and new LTS releases cut.
Reacted by Marcin Pawelek, Joost van Doremalen, michastreppel, Valentin Hervieu, Jeff McLean, Josh Leder, Bryce Steinhoff, Rémy Bach, Simon Plenderleith, Elad Yosifon and 32 moreThis affects us also, as our headers are right around 8k usually, but sometimes more (we have JWT tokens which account for > half of this).
Our base Docker images were locked to a Node major version, so this breaking change appeared out of nowhere when the upstream image updated the Node minor version.
Reacted by Diego Martins, Daniel Junqueira, Al Kemner and 1I1III1liL1It breaks ABI, but I'm not sure if we worry about that with the http parser.
http-parser does, as do distros that link node to http-parser dynamically.
A possible way forward: split
p->nreadinto two,p->nreadandp->nread_max, possibly with better names. :-)Drawback: there are some downstream projects that read
p->nread, even though it's marked as private.@bnoordhuis what about a function that would allow setting the global max header size? It's not necessarily the most elegant solution ever, but I don't think it would break anything.
That could work. Two issues with the patch:
- Don't use a k prefix if it's not actually constant.
- Set the limit once, not every time a new parser is instantiated.
A week of debugging finally brought me here....
could of been easily solved if there was a simple debug log line that indicates that the request was blockedReacted by Alex Naish, Rémy Bach, Arjun Gadhia, Chris Skilton, Justin, Al Kemner, shYkiSto, Rolando Santamaria Maso, Matt Panton, Rahul Sethi and 40 moreReacted by Valentin Hervieu, Marc Bornträger and loclvThe biggest problem with this 8KB header limit change in my opinion is that it also applies to outbound HTTP requests response header parsing. Without any sort of runtime maximum HTTP header size parameter that can be defined in http request, Node.js will start throwing HPE_HEADER_OVERFLOW exceptions when parsing responses from external HTTP API calls that have large response headers (which isn't so uncommon when you factor in JWT and CSP headers).
Reacted by Samuel Parkinson, Richard North, Muhammad Bilal Yar and Andreas Jakobsen@mcollina Have you seen the above comment?
Thanks @Fishrock123 for the ping! I didn't see the message.
The biggest problem with this 8KB header limit change in my opinion is that it also applies to outbound HTTP requests response header parsing. Without any sort of runtime maximum HTTP header size parameter that can be defined in http request, Node.js will start throwing HPE_HEADER_OVERFLOW exceptions when parsing responses from external HTTP API calls that have large response headers (which isn't so uncommon when you factor in JWT and CSP headers)
From a technical perspective, I think we could make this setting per-instance of the http parser once we switch to llhttp. I think should be our target.
Note that #24811 is going to make this configurable with a startup option, which is a step in the right direction.@siboulet Regarding the default limit, I'm open to increase it to 10KB or 12KB if it's common to have more than 8KB of headers data. Our assumption was that 8KB was plenty. Would you mind opening a new issue about changing the default value, and making some examples of requests that will trigger this?
53 remaining items
@MylesBorins at least in my use case there is no real than setting it via NODE_OPTIONS
especially since it will fail to run node if the option does not exist.
So running the app requires different command line/env variable depending on the node version it runs
Which can be a bit of a pain (not major).Not sure about the internals but is there any technical limitation that this can't be set per HTTP server instance ?
@yonjah this was backporting all the way back to 6.x... if the flag doesn't exist the version of node most likely does not have the patch to change header size.
Regarding the change itself... the header size is set in the C++ http parser... this is not something that can be changed on a per request basis and is something that needs to be set a single time for the runtime at startup. The variable that can be accessed on
http.maxHeaderSizeis sharing the value that has been set, but by the time it is accessed the C++ code has already been run and cannot be changedReacted by Jeancan anyone please tell me what header and query string limits are in
node version v10.16.0?i am getting 400 errors on requests with long query strings (eg ~15200 bytes) and wondering if it could be caused by some sort of "max limit".
thank you.
@oshihirii The limit for
10.16.0is 8kb: https://github.com/nodejs/node/blob/v10.16.0/src/node_options.h#L119Reacted by Ole Jørgen Brønner and ProgrammingLifethank you very much @rosswilson.
just to clarify - are query strings included in the 8kb header limit?
also, wondering why:
https://nodejs.org/api/http.html#http_http_maxheadersize
states:
http.maxHeaderSizewasadded in: v11.6.0whereas the
10.15.0changelog lists the addition of themaxHeaderSize propertyas anotable change.just curious to know when the 80kb limit was decreased to 8kb.
thanks again.
Reacted by Vic C and ProgrammingLifeReacted by Matvey Reut, Ole Jørgen Brønner and ProgrammingLife@oshihirii I'm not sure, perhaps someone else here can help you with those questions.
Reacted by oshihiriiAccording to my research (i.e. looking at the code) when opening the issue, the request-path (and thus the query-string) does count as header for nodejs, although the RFC for HTTP states otherwise (i.e. path is not a header).
IIRC the Initial Header limit has been introduced with node 10.14.1.Reacted by oshihirii and Ole Jørgen Brønnerthanks very much @zauberpony.
interesting, when i
console.log(req.headers)it doesn't show the query string, but perhapsreq.headersdoes not actually contain all the information included in theheader. i tried loggingreq.header, but that seems to be a function and therefore not loggable :).@oshihirii It does seem like query params are considered headers. Tried a long list of query params (about 10kb) on v10.12.0 vs v10.16.0 and 10.12 responds with a 200 while 10.16 gives a 400.
Reacted by oshihirii, Ole Jørgen Brønner, Lynnic and Vic C@oshihirii It does seem like query params are considered headers. Tried a long list of query params (about 10kb) on v10.12.0 vs v10.16.0 and 10.12 responds with a 200 while 10.16 gives a 400.
It is because this change(big header limit) was applied in 10.14.0, so versions (within 10) small than 10.14.0 will return 200。
I tried numbers of node version
- 8.14.0 no return
- 10.14.0 return 400
- 10.12.0 return 200
- 11.3.0 return 400
- 12.14.0 return 200
- 13.6.0 return 200
I'm confused why version 12 and 13 will return a 200 status?
One point, header limit feature was added in Noverber 10 2018 when 12 and 13 was not released at all.
Could someone clarify it?
Reacted by Saurav M HI'm getting these errors with long query strings!
As per spec, querystring can be unlimited in size.
ps, using the latest express both with node 13.8 and node 12.16.
Any suggestions?I'm getting these errors with long query strings!
As per spec, querystring can be unlimited in size.
ps, using the latest express both with node 13.8 and node 12.16.
Any suggestions?I suggest scrolling up and reading this very informative thread.
querystringmay be unlimited in size, but for use within node it combined with url (protocol+hostname+path) combined with headers can have a default max size of 8kB (It appears that the ticket to have this increased to 16kB is still open since May last year).To find out during runtime what your node instance is set to:
http.maxHeaderSize.
To config node to have a different value, the flag is--max-http-header-size.EDIT:
It appears you can addmaxHeaderSizeproperty to the RequestOptions to override this value. Value in bytes. Dafault: 8192.@gentlefox Where do you set Request options?
I'm looking here: http://expressjs.com/en/4x/api.html#reqIs there an example?
(for sure this needs to be programmatic and not a CLI)
Within your services.
Express "request" and "response" are essentially Node'shttp(s).request()andhttp(s).response().
Read the Nodejs documentation:(https://nodejs.org/api/http.html#http_http_request_options_callback) and also the https equivalent, which simply adds these tls.connect() options to the available http.request options: ca, cert, ciphers, clientCertEngine, crl, dhparam, ecdhCurve, honorCipherOrder, key, passphrase, pfx, rejectUnauthorized, secureOptions, secureProtocol, servername, sessionIdContext.If unsure, compare with the Express.js code:
latest: https://github.com/expressjs/express/blob/master/lib/request.js
v4: https://github.com/expressjs/express/blob/4.x/lib/request.jsYou'll see Express.js as a convenience utility that simplifies using native Node.js.
Is your feature request related to a problem? Please describe.
The recent limitation to HTTP_MAX_HEADER_SIZE (1860352) to mitigate CVE-2018-12121 is a problem for us.
We use headers internally to communicate the users' session, and sometimes (legitimate) requests from "outside" exceeed the 8 kb limit, too.
Given that JWT-strings easily exceed 1kb, I think the 8kb limit might be too little for others, too.
Or referrer-headers (especially in combination with payment-systems back-and-forth) tend to exceed 1kb, too.
Describe the solution you'd like
Have the possibility to configure the HTTP_MAX_HEADER_SIZE — at least via configuration-flag (at node-compile-time).
Setting this at run-time or at startup time would be nice, too.
Is setting this at compile time already possible? I couldn't find the option or best way to do it for node-gyp/gyp.
Describe alternatives you've considered
patching nodejs at compile time… not a good idea.
Reduce headers, yeah, would be nice, but that means completely changing parts of our architecture.