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/cache/if-modified-since.vtc

155 lines
4.6 KiB
Plaintext
Raw Normal View History

MINOR: cache: Process the If-Modified-Since header in conditional requests If a client sends a conditional request containing an If-Modified-Since header (and no If-None-Match header), we try to compare the date with the one stored in the cache entry (coming either from a Last-Modified head, or a Date header, or corresponding to the first response's reception time). If the request's date is earlier than the stored one, we send a "304 Not Modified" response back. Otherwise, the stored is sent (through a 200 OK response). This resolves GitHub issue #821.
2020-10-23 08:51:28 +00:00
varnishtest "If-Modified-Since support"
#REQUIRE_VERSION=2.3
feature ignore_unknown_macro
server s1 {
# Response containing a "Last-Modified" field
rxreq
expect req.url == "/last_modified"
txresp -nolen -hdr "Transfer-Encoding: chunked" \
-hdr "Last-Modified: Thu, 15 Oct 2020 22:23:24 GMT"
chunkedlen 15
chunkedlen 15
chunkedlen 15
chunkedlen 0
# Response containing a "Date" field
rxreq
expect req.url == "/date"
txresp -nolen -hdr "Transfer-Encoding: chunked" \
MEDIUM: cache: Change caching conditions Do not cache responses that do not have an explicit expiration time (s-maxage or max-age Cache-Control directives or Expires header) or a validator (ETag or Last-Modified headers) anymore, as suggested in RFC 7234#3. The TX_FLAG_IGNORE flag is used instead of the TX_FLAG_CACHEABLE so as not to change the behavior of the checkcache option.
2020-11-12 10:14:41 +00:00
-hdr "Date: Thu, 22 Oct 2020 16:51:12 GMT" \
-hdr "Cache-Control: max-age=5"
MINOR: cache: Process the If-Modified-Since header in conditional requests If a client sends a conditional request containing an If-Modified-Since header (and no If-None-Match header), we try to compare the date with the one stored in the cache entry (coming either from a Last-Modified head, or a Date header, or corresponding to the first response's reception time). If the request's date is earlier than the stored one, we send a "304 Not Modified" response back. Otherwise, the stored is sent (through a 200 OK response). This resolves GitHub issue #821.
2020-10-23 08:51:28 +00:00
chunkedlen 16
chunkedlen 16
chunkedlen 16
chunkedlen 0
# Response containing both a "Last-Modified" and a "Date" fields
# Should behave the same way as if the "Date" field was not here.
rxreq
expect req.url == "/last_modified_and_date"
txresp -nolen -hdr "Transfer-Encoding: chunked" \
-hdr "Last-Modified: Thu, 15 Oct 2020 14:24:38 GMT" \
-hdr "Date: Thu, 22 Oct 2020 16:51:12 GMT"
chunkedlen 17
chunkedlen 17
chunkedlen 17
chunkedlen 0
} -start
haproxy h1 -conf {
REGTESTS: disable inter-thread idle connection sharing on sensitive tests Some regtests involve multiple requests from multiple clients, which can be dispatched as multiple requests to a server. It turns out that the idle connection sharing works so well that very quickly few connections are used, and regularly some of the remaining idle server connections time out at the moment they were going to be reused, causing those random "HTTP header incomplete" traces in the logs that make them fail often. In the end this is only an artefact of the test environment. And indeed, some tests like normalize-uri which perform a lot of reuse fail very often, about 20-30% of the times in the CI, and 100% of the time in local when running 1000 tests in a row. Others like ubase64, sample_fetches or vary_* fail less often but still a lot in tests. This patch addresses this by adding "tune.idle-pool.shared off" to all tests which have at least twice as many requests as clients. It proves very effective as no single error happens on normalize-uri anymore after 10000 tests. Also 100 full runs of all tests yield no error anymore. One test is tricky, http_abortonclose, it used to fail ~10 times per 1000 runs and with this workaround still fails once every 1000 runs. But the test is complex and there's a warning in it mentioning a possible issue when run in parallel due to a port reuse.
2021-05-09 12:41:41 +00:00
global
# WT: limit false-positives causing "HTTP header incomplete" due to
# idle server connections being randomly used and randomly expiring
# under us.
tune.idle-pool.shared off
MINOR: cache: Process the If-Modified-Since header in conditional requests If a client sends a conditional request containing an If-Modified-Since header (and no If-None-Match header), we try to compare the date with the one stored in the cache entry (coming either from a Last-Modified head, or a Date header, or corresponding to the first response's reception time). If the request's date is earlier than the stored one, we send a "304 Not Modified" response back. Otherwise, the stored is sent (through a 200 OK response). This resolves GitHub issue #821.
2020-10-23 08:51:28 +00:00
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}"
MINOR: cache: Process the If-Modified-Since header in conditional requests If a client sends a conditional request containing an If-Modified-Since header (and no If-None-Match header), we try to compare the date with the one stored in the cache entry (coming either from a Last-Modified head, or a Date header, or corresponding to the first response's reception time). If the request's date is earlier than the stored one, we send a "304 Not Modified" response back. Otherwise, the stored is sent (through a 200 OK response). This resolves GitHub issue #821.
2020-10-23 08:51:28 +00:00
frontend fe
bind "fd@${fe}"
default_backend test
backend test
http-request cache-use my_cache
server www ${s1_addr}:${s1_port}
http-response cache-store my_cache
REG-TESTS: cache: Remove T-E header for 304-Not-Modified responses VTEST does not properly handle 304-Not-Modified responses. If a Transfer-Encoding header (and probably a Content-Lenght header too), it waits for a body. Waiting for a fix, the Transfer-Encoding encoding of cached responses in 2 VTEST scripts are removed. Note it is now an issue because of a fix in the H1 multiplexer : * 226082d13a "BUG/MINOR: mux-h1: Do not send a last null chunk on body-less answers" This patch must be backported with the above commit.
2022-11-16 16:19:42 +00:00
# Remove Transfer-Encoding header because of a vtest issue with
# 304-Not-Modified responses
http-after-response del-header transfer-encoding if { status eq 304 }
MINOR: cache: Process the If-Modified-Since header in conditional requests If a client sends a conditional request containing an If-Modified-Since header (and no If-None-Match header), we try to compare the date with the one stored in the cache entry (coming either from a Last-Modified head, or a Date header, or corresponding to the first response's reception time). If the request's date is earlier than the stored one, we send a "304 Not Modified" response back. Otherwise, the stored is sent (through a 200 OK response). This resolves GitHub issue #821.
2020-10-23 08:51:28 +00:00
cache my_cache
total-max-size 3
max-age 20
max-object-size 3072
} -start
client c1 -connect ${h1_fe_sock} {
txreq -url "/last_modified"
rxresp
expect resp.status == 200
expect resp.bodylen == 45
txreq -url "/date"
rxresp
expect resp.status == 200
expect resp.bodylen == 48
txreq -url "/last_modified_and_date"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
# Earlier date
# "Last-Modified" version
txreq -url "/last_modified" \
-hdr "If-Modified-Since: Thu, 15 Oct 2020 00:00:01 GMT"
rxresp
expect resp.status == 200
expect resp.bodylen == 45
# "Date" version
txreq -url "/date" \
-hdr "If-Modified-Since: Thu, 01 Oct 2020 00:00:01 GMT"
rxresp
expect resp.status == 200
expect resp.bodylen == 48
# "Last-Modified" and "Date" version
txreq -url "/last_modified_and_date" \
-hdr "If-Modified-Since: Thu, 15 Oct 2020 00:00:01 GMT"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
# Same date
# "Last-Modified" version
txreq -url "/last_modified" \
-hdr "If-Modified-Since: Thu, 15 Oct 2020 22:23:24 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
# "Date" version
txreq -url "/date" \
-hdr "If-Modified-Since: Thu, 22 Oct 2020 16:51:12 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
# "Last-Modified" and "Date" version
txreq -url "/last_modified_and_date" \
-hdr "If-Modified-Since: Thu, 15 Oct 2020 16:51:12 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
# Later date
# "Last-Modified" version
txreq -url "/last_modified" \
-hdr "If-Modified-Since: Thu, 22 Oct 2020 23:00:00 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
# "Date" version
txreq -url "/date" \
-hdr "If-Modified-Since: Thu, 22 Oct 2020 23:00:00 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
# "Last-Modified" and "Date" version
txreq -url "/last_modified_and_date" \
-hdr "If-Modified-Since: Thu, 22 Oct 2020 23:00:00 GMT"
rxresp
expect resp.status == 304
expect resp.bodylen == 0
} -run