fix: set multipart flags on invalid C-D header, align tests - #3651

This PR was inspired by a bit wider, but similar for v3, #3650.

what

1. Parser flags for invalid part headers (apache2/msc_multipart.c)

• MULTIPART_INVALID_PART (flag_invalid_part) is now set in multipart_process_part_header() when:
  • the part has no Content-Disposition header,
    -*the Content-Disposition header cannot be parsed (any negative result of multipart_parse_content_disposition()),
  • the name parameter is missing.
• MULTIPART_INVALID_QUOTING (flag_invalid_quoting) is now also set when filename* has no valid charset before the first ' (error -16, e.g. a quoted filename*="UTF-8''...").

2. Regression tests check the parser state flags

• tests/regression/target/10-variable-multipart_strict_error.t: seven cases now also match the logged flag values (error => [...]), the same as their v3 counterparts in variable-MULTIPART_STRICT_ERROR.json:
  • duplicate Content-Type part header: DH 1
  • filename* invalid syntax (-17): IQ 1
  • duplicate filename, duplicate filename*, duplicate filename after filename*: DH 1, IQ 0, IP 1
  • invalid percent-encoding in filename* (%ZZ, -18): DH 0, IQ 0, IP 1
  • quoted filename* (-16): DH 0, IQ 1, IP 1
• tests/regression/misc/00-multipart-parser.t: the two "multipart mixed" cases log the flag values in the msg of the strict rule and check IP 1, as in v3.
• The PARSER_STATE logdata and the new msg use RE %{REQBODY_ERROR} instead of PE %{REQBODY_PROCESSOR_ERROR}.

why

Flags. Unlike v3, the v2 parser already stops at the first invalid part header, because multipart_process_part_header() returns -1. However, these error paths only set the request body error. The individual flags stayed 0, so a rule or log line checking MULTIPART_INVALID_PART gave no hint that the part itself was invalid. With this change, v2 reports the same flag values as v3 for the same requests:

• an invalid, missing or nameless Content-Disposition makes the part invalid,
• a filename* without a valid charset is a quoting problem.

Tests. The existing cases only checked the debug log message, so the flag values were never verified. The five PARSER_STATE actions referenced REQBODY_PROCESSOR_ERROR. That variable was removed in 2.9.14 (#3578), so the macro expanded to an empty string (PE ,), and nothing caught it because no test looked at the output. REQBODY_ERROR is the variable v2's modsecurity.conf-recommended uses as well (RE %{REQBODY_ERROR}).

There is no behaviour change for request blocking: these requests were and still are rejected through REQBODY_ERROR. Only the values of MULTIPART_INVALID_PART and MULTIPART_INVALID_QUOTING change, and therefore MULTIPART_STRICT_ERROR, which already was 1 through the request body error.

references

• v3 counterpart: V3/multipart part header errors #3650. In v3 the same cases also suffered from process_part_header() returning 0 instead of -1 on error, which let parsing continue and produced false MULTIPART_DUPLICATE_PART_HEADER values. v2 was not affected by that part.
• Remove deprecated REQBODY_PROCESSOR_ERROR and REQBODY_PROCESSOR_ERROR_MSG #3578: removal of REQBODY_PROCESSOR_ERROR in v2
• V3/master3017 #3647: review comment on the v3 test expectations that started this investigation