RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/http-rules/h1or2_to_h1c.vtc

234 lines
9.6 KiB
Plaintext
Raw Normal View History

REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
varnishtest "Composite HTTP manipulation test (H1 and H2 clear to H1 clear)"
# This config tests several http-request features and their interactions.
# It extracts some samples, places them into variables, modifies some header
# fields, appends multiple identical header fields, overwrites the start line
# using several methods, then dumps the initial list of variables and the final
# one, then applies CRC32 to these values as signatures that are easy to test.
# Then it does it again in the backend after saving the current headers into
# the same names prefixed by "fe-". Then it does the same on the response path.
# If some modifications are performed, the crc values need to be adjusted based
# on the failed logs.
#
# Run it with HAPROXY_PROGRAM=$PWD/haproxy varnishtest -l -k -t 1 "$1"
feature ignore_unknown_macro
server s1 {
rxreq
txresp \
-status 234 \
-hdr "hdr1: val1" \
-hdr "hdr2: val2a" \
-hdr "hdr2: val2b" \
-hdr "hdr3: val3a, val3b" \
-hdr "hdr4:" \
-body "This is a body"
expect req.method == "GET"
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
expect req.http.fe-sl1-crc == 1874847043
expect req.http.fe-sl2-crc == 1142278307
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
expect req.http.fe-hdr-crc == 1719311923
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
expect req.http.be-sl1-crc == 3455320059
expect req.http.be-sl2-crc == 2509326257
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
expect req.http.be-hdr-crc == 3634102538
} -repeat 2 -start
haproxy h1 -conf {
defaults
mode http
REGTESTS: extend the default I/O timeouts and make them overridable With the CI occasionally slowing down, we're starting to see again some spurious failures despite the long 1-second timeouts. This reports false positives that are disturbing and doesn't provide as much value as this could. However at this delay it already becomes a pain for developers to wait for the tests to complete. This commit adds support for the new environment variable HAPROXY_TEST_TIMEOUT that will allow anyone to modify the connect, client and server timeouts. It was set to 5 seconds by default, which should be plenty for quite some time in the CI. All relevant values that were 200ms or above were replaced by this one. A few larger values were left as they are special. One test for the set-timeout action that used to rely on a fixed 1-sec value was extended to a fixed 5-sec, as the timeout is normally not reached, but it needs to be known to compare the old and new values.
2021-11-18 16:46:22 +00:00
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
frontend fe
bind "fd@${feh1}"
bind "fd@${feh2}" proto h2
#### requests
http-request set-var(req.method) method
http-request set-var(req.uri) url
http-request set-var(req.path) path
http-request set-var(req.query) query
http-request set-var(req.param) url_param(qs_arg)
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-var(req.cl) req.fhdr(content-length)
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header sl1 "sl1: "
http-request set-method "%[str(GET)]"
REGTEST: Fix format of set-uri HTTP request rule in h1or2_to_h1c.vtc First, concat() is a converter, not a sample fetch. So use str() sample fetch with no string and call concat on it. Then, the argument of the set-uri rule must be a log format string. So it must be inside %[] to be evaluated.
2020-01-17 22:21:59 +00:00
http-request set-uri %[str(),concat(/bu/,req.uri,/eu)]
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-path "/bp/%[var(req.path)]/ep"
http-request set-query "bq&%[var(req.query)]&eq"
http-request set-header sl2 "sl2: "
http-request set-header sl1 "%[req.fhdr(sl1)] method=<%[var(req.method)]>; uri=<%[var(req.uri)]>; path=<%[var(req.path)]>;"
http-request set-header sl1 "%[req.fhdr(sl1)] query=<%[var(req.query)]>; param=<%[var(req.param)]>"
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-header sl1 "%[req.fhdr(sl1)] cl=<%[var(req.cl)]>"
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header sl2 "%[req.fhdr(sl2)] method=<%[method]>; uri=<%[url]>; path=<%[path]>; "
http-request set-header sl2 "%[req.fhdr(sl2)] query=<%[query]>; param=<%[url_param(qs_arg)]>"
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-header sl2 "%[req.fhdr(sl2)] cl=<%[req.fhdr(content-length)]>"
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header hdr "%[req.fhdr(hdr)] hdr1=<%[req.hdr(hdr1)]>; fhdr1=<%[req.fhdr(hdr1)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr2=<%[req.hdr(hdr2)]>; fhdr2=<%[req.fhdr(hdr2)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr3=<%[req.hdr(hdr3)]>; fhdr3=<%[req.fhdr(hdr3)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr4=<%[req.hdr(hdr4)]>; fhdr4=<%[req.fhdr(hdr4)]>;"
http-request set-header sl1-crc "%[req.fhdr(sl1),crc32]"
http-request set-header sl2-crc "%[req.fhdr(sl2),crc32]"
http-request set-header hdr-crc "%[req.fhdr(hdr),crc32]"
#### responses
http-response set-header be-sl1 "%[res.fhdr(sl1)]"
http-response set-header be-sl2 "%[res.fhdr(sl2)]"
http-response set-header be-hdr "%[res.fhdr(hdr)]"
http-response set-header be-sl1-crc "%[res.fhdr(sl1-crc)]"
http-response set-header be-sl2-crc "%[res.fhdr(sl2-crc)]"
http-response set-header be-hdr-crc "%[res.fhdr(hdr-crc)]"
http-response set-var(res.status) status
http-response set-header sl1 "sl1: "
http-response set-status 200
http-response set-header sl2 "sl2: "
http-response set-header sl1 "%[res.fhdr(sl1)] status=<%[var(res.status)]>;"
http-response set-header sl2 "%[res.fhdr(sl2)] status=<%[status]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr1=<%[res.hdr(hdr1)]>; fhdr1=<%[res.fhdr(hdr1)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr2=<%[res.hdr(hdr2)]>; fhdr2=<%[res.fhdr(hdr2)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr3=<%[res.hdr(hdr3)]>; fhdr3=<%[res.fhdr(hdr3)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr4=<%[res.hdr(hdr4)]>; fhdr4=<%[res.fhdr(hdr4)]>;"
http-response set-header fe-sl1-crc "%[res.fhdr(sl1),crc32]"
http-response set-header fe-sl2-crc "%[res.fhdr(sl2),crc32]"
http-response set-header fe-hdr-crc "%[res.fhdr(hdr),crc32]"
default_backend be
backend be
#### requests
http-request set-header fe-sl1 "%[req.fhdr(sl1)]"
http-request set-header fe-sl2 "%[req.fhdr(sl2)]"
http-request set-header fe-hdr "%[req.fhdr(hdr)]"
http-request set-header fe-sl1-crc "%[req.fhdr(sl1-crc)]"
http-request set-header fe-sl2-crc "%[req.fhdr(sl2-crc)]"
http-request set-header fe-hdr-crc "%[req.fhdr(hdr-crc)]"
http-request set-var(req.method) method
http-request set-var(req.uri) url
http-request set-var(req.path) path
http-request set-var(req.query) query
http-request set-var(req.param) url_param(qs_arg)
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-var(req.cl) req.fhdr(content-length)
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header sl1 "sl1: "
http-request set-method "%[str(GET)]"
REGTEST: Fix format of set-uri HTTP request rule in h1or2_to_h1c.vtc First, concat() is a converter, not a sample fetch. So use str() sample fetch with no string and call concat on it. Then, the argument of the set-uri rule must be a log format string. So it must be inside %[] to be evaluated.
2020-01-17 22:21:59 +00:00
http-request set-uri %[str(),concat(/bu/,req.uri,/eu)]
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-path "/bp/%[var(req.path)]/ep"
http-request set-query "bq&%[var(req.query)]&eq"
http-request set-header sl2 "sl2: "
http-request set-header sl1 "%[req.fhdr(sl1)] method=<%[var(req.method)]>; uri=<%[var(req.uri)]>; path=<%[var(req.path)]>;"
http-request set-header sl1 "%[req.fhdr(sl1)] query=<%[var(req.query)]>; param=<%[var(req.param)]>"
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-header sl1 "%[req.fhdr(sl1)] cl=<%[var(req.cl)]>"
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header sl2 "%[req.fhdr(sl2)] method=<%[method]>; uri=<%[url]>; path=<%[path]>; "
REGTESTS : Add test support for case insentitive for url_param Test using case insensitive is supported in /reg-tests/http-rules/h1or2_to_h1c.vtc
2023-03-30 13:03:36 +00:00
http-request set-header sl2 "%[req.fhdr(sl2)] query=<%[query]>; param=<%[url_param(QS_arg,,i)]>"
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
http-request set-header sl2 "%[req.fhdr(sl2)] cl=<%[req.fhdr(content-length)]>"
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
http-request set-header hdr "%[req.fhdr(hdr)] hdr1=<%[req.hdr(hdr1)]>; fhdr1=<%[req.fhdr(hdr1)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr2=<%[req.hdr(hdr2)]>; fhdr2=<%[req.fhdr(hdr2)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr3=<%[req.hdr(hdr3)]>; fhdr3=<%[req.fhdr(hdr3)]>;"
http-request set-header hdr "%[req.fhdr(hdr)] hdr4=<%[req.hdr(hdr4)]>; fhdr4=<%[req.fhdr(hdr4)]>;"
http-request set-header be-sl1-crc "%[req.fhdr(sl1),crc32]"
http-request set-header be-sl2-crc "%[req.fhdr(sl2),crc32]"
http-request set-header be-hdr-crc "%[req.fhdr(hdr),crc32]"
#### responses
http-response set-var(res.status) status
http-response set-header sl1 "sl1: "
http-response set-status 200
http-response set-header sl2 "sl2: "
http-response set-header sl1 "%[res.fhdr(sl1)] status=<%[var(res.status)]>;"
http-response set-header sl2 "%[res.fhdr(sl2)] status=<%[status]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr1=<%[res.hdr(hdr1)]>; fhdr1=<%[res.fhdr(hdr1)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr2=<%[res.hdr(hdr2)]>; fhdr2=<%[res.fhdr(hdr2)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr3=<%[res.hdr(hdr3)]>; fhdr3=<%[res.fhdr(hdr3)]>;"
http-response set-header hdr "%[res.fhdr(hdr)] hdr4=<%[res.hdr(hdr4)]>; fhdr4=<%[res.fhdr(hdr4)]>;"
http-response set-header sl1-crc "%[res.fhdr(sl1),crc32]"
http-response set-header sl2-crc "%[res.fhdr(sl2),crc32]"
http-response set-header hdr-crc "%[res.fhdr(hdr),crc32]"
BUG/MINOR: http-ana: Apply stop to the current section for http-response rules A TCP/HTTP action can stop the rules evaluation. However, it should be applied on the current section only. For instance, for http-requests rules, an "allow" on a frontend must stop evaluation of rules defined in this frontend. But the backend rules, if any, must still be evaluated. For http-response rulesets, according the configuration manual, the same must be true. Only "allow" action is concerned. However, since the beginning, this action stops evaluation of all remaining rules, not only those of the current section. This patch may be backported to all supported versions. But it is not so critical because the bug exists since a while. I doubt it will break any existing configuration because the current behavior is counterintuitive.
2021-11-09 15:33:25 +00:00
http-response allow
http-response deny # must not be evaluated
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
server s1 ${s1_addr}:${s1_port}
} -start
client c1h1 -connect ${h1_feh1_sock} {
txreq \
-req GET \
-url /path/to/file.extension?qs_arg=qs_value \
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
-hdr "content-length: 000, 00" \
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
-hdr "hdr1: val1" \
-hdr "hdr2: val2a" \
-hdr "hdr2: val2b" \
-hdr "hdr3: val3a, val3b" \
-hdr "hdr4:"
rxresp
expect resp.status == 200
expect resp.http.be-sl1-crc == 487202719
expect resp.http.be-sl2-crc == 561949791
expect resp.http.be-hdr-crc == 1719311923
expect resp.http.fe-sl1-crc == 146151597
expect resp.http.fe-sl2-crc == 561949791
expect resp.http.fe-hdr-crc == 3634102538
expect resp.bodylen == 14
expect resp.body == "This is a body"
} -run
client c1h2 -connect ${h1_feh2_sock} {
REGTESTS: adjust the http-rules regtest to support window updates Varnishtest is not happy to see the window update come before the settings ACK, as by default it expects exactly tx/rx/txack/rxack. One workaround could consist in making haproxy send the WU after the settings ACK but this would be a real hack as the preface is already finished when sending this ack. Instead, let's make the initial sequence explicit in the tests.
2018-12-13 16:29:20 +00:00
txpri
stream 0 {
txsettings
rxsettings
txsettings -ack
rxsettings
expect settings.ack == true
} -run
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
stream 1 {
# warning: -req, -scheme, -url MUST be placed first otherwise
# the H2 protocol is invalid since they are pseudo-headers
txreq \
-req GET \
-scheme "https" \
-url /path/to/file.extension?qs_arg=qs_value \
BUG/MINOR: http: skip leading zeroes in content-length values Ben Kallus also noticed that we preserve leading zeroes on content-length values. While this is totally valid, it would be safer to at least trim them before passing the value, because a bogus server written to parse using "strtol(value, NULL, 0)" could inadvertently take a leading zero as a prefix for an octal value. While there is not much that can be done to protect such servers in general (e.g. lack of check for overflows etc), at least it's quite cheap to make sure the transmitted value is normalized and not taken for an octal one. This is not really a bug, rather a missed opportunity to sanitize the input, but is marked as a bug so that we don't forget to backport it to stable branches. A combined regtest was added to h1or2_to_h1c which already validates end-to-end syntax consistency on aggregate headers.
2023-08-09 09:02:34 +00:00
-hdr "content-length" "000, 00" \
REGTEST: make the HTTP rules test compatible with HTTP/2 as well The HTTP rules test now runs an H1 and an H2 client. Since the H2 one requires the "proto" directive on the bind line, a new file has been created requiring version 1.9 and the previous one was marked as usable below 1.9 so that it's skipped by default but still usable when testing backports.
2018-12-07 17:21:21 +00:00
-hdr "hdr1" "val1" \
-hdr "hdr2" " val2a" \
-hdr "hdr2" " val2b" \
-hdr "hdr3" " val3a, val3b" \
-hdr "hdr4" ""
rxhdrs
expect resp.status == 200
expect resp.http.be-sl1-crc == 487202719
expect resp.http.be-sl2-crc == 561949791
expect resp.http.be-hdr-crc == 1719311923
expect resp.http.fe-sl1-crc == 146151597
expect resp.http.fe-sl2-crc == 561949791
expect resp.http.fe-hdr-crc == 3634102538
expect resp.http.content-length == 14
rxdata -all
expect resp.body == "This is a body"
} -run
} -run