GeezerVison

What's the reasoning for changing this check? Before this PR, it was not accepted to have headersTimeout equals to requestTimeout. You mentioned the docs in the OP, but I don't seem to find that; could you link to where you've read that?

@aduh95 a request can be complete when the headers have been finished. Looking at the code and the docs for headersTimeout and requestTimeout, it's imho clear that the intention is/was that headersTimeout<=requestTimeout. Additionally people like to be able to set their arguments logically, so requiring that requestTimeout needs to be 1001 if you want headersTimeout to be 1000 is silly.

As I said in my previous comment, I wasn't able to find that in the docs. When referring to the docs, it'd be helpful to quote the exact docs so we know we're talking of the same thing (or even better use the permalink feature of GitHub). (and if it is not in the docs, that's also fine, but in this case you shouldn't say "According to the documentation and also logic", but rather "According to me": that'd still be a valid reason to make that change and reviewers wouldn't waste time reading the docs looking for something that's not there 😉)

Since it is a behavior change, we should add an history entry to the YAML comment. That would look something like this (but with a different pr-url & description of course):

it's imho clear that the intention is/was that headersTimeout<=requestTimeout

Let's not assume intent, I don't think that's relevant, and it's easy to get wrong.

requiring that requestTimeout needs to be 1001 if you want headersTimeout to be 1000 is silly.

I agree that does seem to be an unnecessary requirement – unless I'm missing something? @ShogunPanda when you said it's redundant, do you mean that users should just remove headersTimeout if it's set to the same value as requestTimeout?

Apologies, I was arrogant. I appreciate you being kind to me.

Yes, the docs don't cleanly say that it must be x. I take it as implied, since the docs say:

For headersTimeout
"Limit the amount of time the parser will wait to receive the complete HTTP headers."

For requestTimeout
"Sets the timeout value in milliseconds for receiving the entire request from the client."

and a complete entire request can be just the http headers.

but implication is also easy to get wrong.

I wish it was so, that we could cleanly set headersTimeout as <= of requestTimeout. It allows explicitly defining what happens, and would, in my opinion, be logical.