haproxy/reg-tests/http-messaging
Christopher Faulet 25bcdb1d95 BUG/MAJOR: h1: Be stricter on request target validation during message parsing
As stated in issue #2565, checks on the request target during H1 message
parsing are not good enough. Invalid paths, not starting by a slash are in
fact parsed as authorities. The same error is repeated at the sample fetch
level. This last point is annoying because routing rules may be fooled. It
is also an issue when the URI or the Host header are updated.

Because the error is repeated at different places, it must be fixed. We
cannot be lax by arguing it is the server's job to accept or reject invalid
request targets. With this patch, we strengthen the checks performed on the
request target during H1 parsing. Idea is to reject invalid requests at this
step to be sure it is safe to manipulate the path or the authority at other
places.

So now, the asterisk-form is only allowed for OPTIONS and OTHER methods.
This last point was added to not reject the H2 preface. In addition, we take
care to have only one asterisk and nothing more. For the CONNECT method, we
take care to have a valid authority-form. All other form are rejected. The
authority-form is now only supported for CONNECT method. No specific check
is performed on the origin-form (except for the CONNECT method). For the
absolute-form, we take care to have a scheme and a valid authority.

These checks are not perfect but should be good enough to properly identify
each part of the request target for a relative small cost. But, it is a
breaking change. Some requests are now be rejected while they was not on
older versions. However, nowadays, it is most probably not an issue.  If it
turns out it's really an issue for legitimate use-cases, an option would be
to supports these kinds of requests when the "accept-invalid-http-request"
option is set, with the consequence of seeing some sample fetches having an
unexpected behavior.

This patch should fix the issue #2665. It MUST NOT be backported. First
because it is a breaking change. And then because by avoiding backporting
it, it remains possible to relax the parsing with the
"accept-invalid-http-request" option.
2024-05-15 21:20:37 +02:00
..
common.pem
h1_host_normalization.vtc REGTESTS: h1_host_normalization : Add a barrier to not mix up log messages 2023-06-20 12:49:39 +02:00
h1_request_target_validation.vtc BUG/MAJOR: h1: Be stricter on request target validation during message parsing 2024-05-15 21:20:37 +02:00
h1_to_h1.vtc BUG/MAJOR: http: reject any empty content-length header value 2023-08-09 09:27:38 +02:00
h2_desync_attacks.vtc
h2_to_h1.vtc BUG/MAJOR: http: reject any empty content-length header value 2023-08-09 09:27:38 +02:00
http_abortonclose.vtc REGTESTS: http: Improve script testing abortonclose option 2023-11-14 11:01:51 +01:00
http_bodyless_response.vtc REGTESTS: http: Create a dedicated script to test spliced bodyless responses 2023-08-04 15:02:19 +02:00
http_bodyless_spliced_response.vtc REGTESTS: Test SPLICE feature is enabled to execute script about splicing 2023-08-04 15:08:06 +02:00
http_msg_full_on_eom.vtc
http_request_buffer.vtc
http_splicing.vtc REGTESTS: Reenable HTTP tests about splicing 2023-10-17 18:51:13 +02:00
http_splicing_chunk.vtc REGTESTS: Reenable HTTP tests about splicing 2023-10-17 18:51:13 +02:00
http_transfer_encoding.vtc
http_wait_for_body.vtc
protocol_upgrade.vtc
scheme_based_normalize.vtc
srv_ws.vtc REGTESTS: wolfssl: temporarly disable some failing reg-tests 2023-10-09 23:05:18 +02:00
truncated.vtc REGTESTS: Remove REQUIRE_VERSION=1.9 from all tests (2) 2024-04-02 07:27:33 +02:00
websocket.vtc