Thanks @ffurano for the pull request. I just have two small observations: I see that more established HTTP servers have bigger thresholds when it comes to the max size of the header e.g. Apache 8K, Nginx 4-8K, Tomcat 8-48K. Maybe it would be good to align with some of these?! How about sending a 400 or 403 responseto the client so that it clear also on the client side why the server dropped the connection?

Hi @esindril
there's a misunderstanding here I think, the limit I have put (4K) is for a single line in the header... overall the header can be of infinite size :-)

I see the idea behind the 400 response, yet I am puzzled by the usefulness of sending a response to a corrupted header request... anyway could you please confirm whether this little addition fixes your issue? I'll merge it in anyway because it's a protection that makes sense to me.

Sorry for being vague - indeed referring to line size, for example Apache has 8K
https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestline
This should not be an issue in general, except for very long cookies ... It would probably be best that this is a configurable value.

I will run some tests with this patch and I will let you know if I see any issues. Thanks!

FWIW - given the increased use of tokens (which can embed paths internally), I wouldn't mind bumping the defaults to 8K.

huh really 8K for a line... wow I had understood you referred to the header, sorry...

Technically speaking, inside the code every value up to the buffer size (1MB) can be used for a single line

We do 16K then ?

Done... please let me know if the fix works fine

I gave it a try but this only fails if the header line is greater than 1MB and not the expected 4KB/16KB. I think the comparison with the maximum allowed header line should use the tmpline variable rather than BuffUsed().
https://github.com/xrootd/xrootd/pull/1304/files#diff-9e14c507e3987861e248439b73604209R611

The looping effect is gone. @simonmichal could you please back-port this to 4.12.5? Thanks!