Set correct line end in case of MULTIPART_PART_HEADER variable

[airween]

Looks like variable MULTIPART_PART_HEADER variable contains the EOL characters.

This can lead false positive, and we (CRS team) discovered with help of an issue 3046. There is a full detail of the unexpected behavior, with many examples.

Here is what I get in the debug.log:

Multipart: Added part header "Content-Disposition" "form-data; name="file"; filename="New Text Document.txt"".
Multipart: Added part header "Content-Type" "text/plain; charset=utf-8".
Multipart: Content-Disposition name: file.
Multipart: Content-Disposition filename: New Text Document.txt.
MultipartPartTmpFile: Create filename= /tmp/20230128-212401-16749374418.382181-file-uEZjC1
Multipart: Created temporary file 1 (mode o0): /tmp/20230128-212401-16749374418.382181-file-uEZjC1
Multipart: Added part header line:Content-Disposition: form-data; name="file"; filename="New Text Document.txt"

Multipart: Added part header line:Content-Type: text/plain; charset=utf-8

As it seems, the log contains the Added part header line: with the header of the part of multipart payload. Both lines ended with EOL - but not as like in case of Added part header.

After the fix, the same part of debug log is this:

Multipart: Added part header "Content-Disposition" "form-data; name="file"; filename="New Text Document.txt"".
Multipart: Added part header "Content-Type" "text/plain; charset=utf-8".
Multipart: Content-Disposition name: file.
Multipart: Content-Disposition filename: New Text Document.txt.
MultipartPartTmpFile: Create filename= /tmp/20230128-213008-167493780825.319085-file-89EDD6
Multipart: Created temporary file 1 (mode o0): /tmp/20230128-213008-167493780825.319085-file-89EDD6
Multipart: Added part header line:Content-Disposition: form-data; name="file"; filename="New Text Document.txt"
Multipart: Added part header line:Content-Type: text/plain; charset=utf-8

The lines are without \r\n, and both variables (part header and part header line) are the same. This is the same behavior as in case of mod_security2 (this is why I thought it's an unexpected behavior).

I added a new test case, anyone can check the regression test if picks up that commit.

[martinhsv]

This all looks fine now. Thanks @airween