Exceeding max header count limit

[janos-mands]

Our graphql stack is using uWebSockets and as our consumer base is growing, and our cloud-based infrastructure is getting more mature, we are facing the issue that 50 headers prove to be not enough for all of our consumers. Part of the reason is that besides that browsers add a default set of headers automatically, could infrastructure elements also add various headers, security and observability frameworks also add headers, etc. There is little space left for the client applications to add their own headers.

I am wondering whether it would be possible to make the max headers count configurable so that uWebSockets could provide a secure and performant default value, while those who need to exceed this limit, could set it higher for their own performance and security risk.

I understand that this limit is set by MAX_HEADERS in https://github.com/uNetworking/uWebSockets/blob/master/src/HttpParser.h currently. I have also learnt from https://github.com/uNetworking/uWebSockets/issues/1659 that changing MAX_HEADERS to a runtime overridable value is not as simple as was for MAX_FALLBACK_SIZE, because it would require to change the static array allocation to dynamic heap allocation. But I still hope we can find a solution that could provide the maximum security and performance by default, with a bit more configurability for those who need that trade-off for the sake of their consumers, while still would like to use the original uWebSockets.

I would find it less favourable, but if MAX_HEADERS could not be made configurable, would it be possible to increase the limit higher, e.g. to 100?

Also, it is worth mentioning that when the max header count is exceeded, our client applications are experiencing socket hand up for the related uWebSockets based service process. (We have uWebSockets + additional layers on top, but I believe this behaviour is related to uWebSockets). Could be http 431 (or other explicit error) returned for these cases as well?

[uNetworkingAB]

MAX_HEADERS is not that important so I just raised the default. MAX_FALLBACK_SIZE is important so its default is still 4kb

[janos-mands]

Thanks @uNetworkingAB, appreciate it. It should take us out of the woods for a while.

[janos-mands]

@uNetworkingAB I am just wondering about the release method and cycles of uWebSockets.js. I have seen that a previous release was based on a Bumb uWS commit (https://github.com/uNetworking/uWebSockets.js/commit/79e21c4b3fb29edd420c8aacad5f4cf6b32c19b1) - at least I assume it was triggered by that. Is there any way I could help the current changes make through to a next uWebSockets.js release or it is based on some schedule?

[uNetworkingAB]

There is no schedule but I tend to batch it a bit

[arnabk]

Is there any limit to value for UWS_HTTP_MAX_HEADERS_SIZE. When I use UWS_HTTP_MAX_HEADERS_SIZE=11630, it freezes and I get TIMEOUT_ERROR

[uNetworkingAB]

There is no limit, I just tested 80000 worked fine