Resigning my first attempt to get patches through the 2.2.x process, and revoking my ratification of a list of patches (e.g. -1 as had been applied, including my own submissions - I will revert in any case, where misordered.)
Proposing that we start with the same branch model as used on 2.4.x to get through too many many-year-old patches to idly browse through; replay these in mostly-sequential order, and bring 2.2.x up to 2.4.x in the affected areas of code, and finally this proposal suggests the same merge as was applied to 2.4.25 GA release, modulo all our new crazy APLOGNO fun.
There is not much to see here, other than to compare rev no's of what had been applied/proposed reverts to the list of patches on the 2.2.x merge branch... the interesting data is on that merge branch. But extensive testing against the resulting code is critical to our hope of offering a last 2.2.x release to close that chapter. TIA to each and everyone who assists!
core: Limit to ten the number of tolerated empty lines between request, and consume them before the pipelining check to avoid possible response delay when reading the next request without flushing.
Before this commit, the maximum number of empty lines was the same as configured LimitRequestFields, defaulting to 100, which was way too much. We now use a fixed/hard limit of 10 (DEFAULT_LIMIT_BLANK_LINES).
check_pipeline() is changed to check for (up to the limit) and comsume the trailing [CR]LFs so that they won't be interpreted as pipelined requests, otherwise we would block on the next read without flushing data, and hence possibly delay pending response(s) until the next/real request comes in or the keepalive timeout expires.
Finally, when the maximum number of empty line is reached in read_request_line(), or that request line does not contains at least a method and an (valid) URI, we can fail early and avoid some failure detected in further processing.
* Ensure that proto_num and protocol is set in another "error out early" edge case. This can happen with invalid CONNECT requests as described in the PR.