RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-14 15:34:35 +00:00
Code Issues Packages Projects Releases Wiki Activity
e6cc5b5974
haproxy/reg-tests/cache/vary.vtc

335 lines
10 KiB
Plaintext
Raw Normal View History

MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
varnishtest "Vary support"
#REQUIRE_VERSION=2.3
feature ignore_unknown_macro
server s1 {
# Response varying on "accept-encoding"
rxreq
expect req.url == "/accept-encoding"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Content-Encoding: gzip" \
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
-hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-bodylen 45
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
# Response varying on "accept-encoding"
rxreq
expect req.url == "/accept-encoding"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Content-Type: text/plain" \
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
-hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-bodylen 48
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
# Response varying on "accept-encoding" but having two different encodings
rxreq
expect req.url == "/accept-encoding-multiple"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding" \
-hdr "Cache-Control: max-age=5" \
-bodylen 51
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
# Unmanaged vary
rxreq
expect req.url == "/unmanaged"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding,unmanaged" \
-hdr "Cache-Control: max-age=5" \
-bodylen 51
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
rxreq
expect req.url == "/unmanaged"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding,unmanaged" \
-hdr "Cache-Control: max-age=5" \
-bodylen 51
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
# Mixed Vary (Accept-Encoding + Referer)
rxreq
expect req.url == "/referer-accept-encoding"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding,referer" \
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 51
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
rxreq
expect req.url == "/referer-accept-encoding"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: referer,accept-encoding" \
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 54
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
rxreq
expect req.url == "/referer-accept-encoding"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: referer,accept-encoding" \
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 57
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
# Multiple Accept-Encoding headers
rxreq
expect req.url == "/multiple_headers"
txresp -hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 155
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
rxreq
expect req.url == "/multiple_headers"
txresp -hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 166
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
# Too many Accept-Encoding values (we will not cache responses with more than 16 encodings)
rxreq
expect req.url == "/too_many_encodings"
txresp -hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 177
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
rxreq
expect req.url == "/too_many_encodings"
txresp -hdr "Vary: accept-encoding" \
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
-hdr "Cache-Control: max-age=5" \
-hdr "Content-Encoding: gzip" \
-bodylen 188
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
} -start
server s2 {
# Responses that should not be cached
rxreq
expect req.url == "/no_vary_support"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding" \
-hdr "Cache-Control: max-age=5" \
-bodylen 57
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
rxreq
expect req.url == "/no_vary_support"
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
txresp -hdr "Vary: accept-encoding" \
-hdr "Cache-Control: max-age=5" \
-bodylen 57
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
} -start
haproxy h1 -conf {
defaults
mode http
${no-htx} option http-use-htx
timeout connect 1s
timeout client 1s
timeout server 1s
frontend fe
bind "fd@${fe}"
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
use_backend no_vary_be if { path_beg /no_vary_support }
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
default_backend test
backend test
http-request cache-use my_cache
server www ${s1_addr}:${s1_port}
http-response cache-store my_cache
http-response set-header X-Cache-Hit %[res.cache_hit]
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
backend no_vary_be
http-request cache-use no_vary_cache
server www ${s2_addr}:${s2_port}
http-response cache-store no_vary_cache
http-response set-header X-Cache-Hit %[res.cache_hit]
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
cache my_cache
total-max-size 3
max-age 20
max-object-size 3072
MINOR: cache: Replace the "process-vary" option's expected values Replace the <0/1> expected values of the process-vary option by a more usual <on/off> pair.
2020-12-23 17:13:53 +00:00
process-vary on
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
cache no_vary_cache
total-max-size 3
max-age 20
max-object-size 3072
MINOR: cache: Replace the "process-vary" option's expected values Replace the <0/1> expected values of the process-vary option by a more usual <on/off> pair.
2020-12-23 17:13:53 +00:00
process-vary off
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
} -start
client c1 -connect ${h1_fe_sock} {
# Accept-Encoding Vary
txreq -url "/accept-encoding" -hdr "Accept-Encoding: first_value"
rxresp
expect resp.status == 200
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
expect resp.http.content-encoding == "gzip"
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
expect resp.bodylen == 45
txreq -url "/accept-encoding" -hdr "Accept-Encoding: second_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 48
expect resp.http.content-type == "text/plain"
expect resp.http.X-Cache-Hit == 0
txreq -url "/accept-encoding" -hdr "Accept-Encoding: first_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 45
REGTESTS: cache: Simplify vary.vtc file This test used chunked responses but it is not needed. All the chunked responses are replaced by more simple 'bodylen' directives.
2020-12-23 17:13:50 +00:00
expect resp.http.content-encoding == "gzip"
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
expect resp.http.X-Cache-Hit == 1
txreq -url "/accept-encoding" -hdr "Accept-Encoding: second_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 48
expect resp.http.content-type == "text/plain"
expect resp.http.X-Cache-Hit == 1
MINOR: cache: Improve accept_encoding_normalizer Turn the "Accept-Encoding" value to lower case before processing it. Calculate the CRC on every token instead of a sorted concatenation of them all (in order to avoir copying them) then XOR all the CRCs into a single hash (while ignoring duplicates).
2020-11-30 16:06:03 +00:00
# The accept-encoding normalizer function converts the header values
# to lower case then calculates the hash of every sub part before
# sorting the hashes and xor'ing them (while removing duplicates).
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
txreq -url "/accept-encoding-multiple" -hdr "Accept-Encoding: first,second"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 0
txreq -url "/accept-encoding-multiple" -hdr "Accept-Encoding: first,second"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 1
txreq -url "/accept-encoding-multiple" -hdr "Accept-Encoding: second,first"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 1
MINOR: cache: Improve accept_encoding_normalizer Turn the "Accept-Encoding" value to lower case before processing it. Calculate the CRC on every token instead of a sorted concatenation of them all (in order to avoir copying them) then XOR all the CRCs into a single hash (while ignoring duplicates).
2020-11-30 16:06:03 +00:00
txreq -url "/accept-encoding-multiple" -hdr "Accept-Encoding: FirsT,SECOND,first"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 1
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
# Unmanaged vary
txreq -url "/unmanaged" -hdr "Accept-Encoding: first_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 0
txreq -url "/unmanaged" -hdr "Accept-Encoding: first_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 0
# Mixed Vary (Accept-Encoding + Referer)
txreq -url "/referer-accept-encoding" \
-hdr "Accept-Encoding: first_value,second_value" \
-hdr "Referer: referer"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 0
txreq -url "/referer-accept-encoding" \
-hdr "Accept-Encoding: first_value" \
-hdr "Referer: other-referer"
rxresp
expect resp.status == 200
expect resp.bodylen == 54
expect resp.http.X-Cache-Hit == 0
txreq -url "/referer-accept-encoding" \
-hdr "Accept-Encoding: second_value" \
-hdr "Referer: other-referer"
rxresp
expect resp.status == 200
expect resp.bodylen == 57
expect resp.http.X-Cache-Hit == 0
txreq -url "/referer-accept-encoding" \
-hdr "Referer: referer" \
-hdr "Accept-Encoding: second_value,first_value"
rxresp
expect resp.status == 200
expect resp.bodylen == 51
expect resp.http.X-Cache-Hit == 1
txreq -url "/referer-accept-encoding" \
-hdr "Accept-Encoding: first_value" \
-hdr "Referer: other-referer"
rxresp
expect resp.status == 200
expect resp.bodylen == 54
expect resp.http.X-Cache-Hit == 1
txreq -url "/referer-accept-encoding" \
-hdr "Accept-Encoding: second_value" \
-hdr "Referer: other-referer"
rxresp
expect resp.status == 200
expect resp.bodylen == 57
expect resp.http.X-Cache-Hit == 1
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
BUG/MINOR: cache: Manage multiple headers in accept-encoding normalization The accept-encoding part of the secondary key (vary) was only built out of the first occurrence of the header. So if a client had two accept-encoding headers, gzip and br for instance, the key would have been built out of the gzip string. So another client that only managed gzip would have been sent the cached resource, even if it was a br resource. The http_find_header function is now called directly by the normalizers so that they can manage multiple headers if needed. A request that has more than 16 encodings will be considered as an illegitimate request and its response will not be stored. This fixes GitHub issue #987. It does not need any backport.
2020-12-23 17:13:46 +00:00
# Multiple Accept-encoding headers
txreq -url "/multiple_headers" \
-hdr "Accept-Encoding: first_encoding" \
-hdr "Accept-Encoding: second_encoding,third_encoding"
rxresp
expect resp.status == 200
expect resp.bodylen == 155
expect resp.http.X-Cache-Hit == 0
txreq -url "/multiple_headers" \
-hdr "Accept-Encoding: third_encoding" \
-hdr "Accept-Encoding: second_encoding,first_encoding"
rxresp
expect resp.status == 200
expect resp.bodylen == 155
expect resp.http.X-Cache-Hit == 1
# Should not match a cache entry
txreq -url "/multiple_headers" \
-hdr "Accept-Encoding: first_encoding"
rxresp
expect resp.status == 200
expect resp.bodylen == 166
expect resp.http.X-Cache-Hit == 0
# Too many accept encodings
txreq -url "/too_many_encodings" \
-hdr "Accept-Encoding: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,a17"
rxresp
expect resp.status == 200
expect resp.bodylen == 177
expect resp.http.X-Cache-Hit == 0
txreq -url "/too_many_encodings" \
-hdr "Accept-Encoding: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10,a11,a12,a13,a14,a15,a16,a17"
rxresp
expect resp.status == 200
expect resp.bodylen == 188
expect resp.http.X-Cache-Hit == 0
MINOR: cache: Improve accept_encoding_normalizer Turn the "Accept-Encoding" value to lower case before processing it. Calculate the CRC on every token instead of a sorted concatenation of them all (in order to avoir copying them) then XOR all the CRCs into a single hash (while ignoring duplicates).
2020-11-30 16:06:03 +00:00
# The following requests are treated by a backend that does not cache
MINOR: cache: Add a process-vary option that can enable/disable Vary processing The cache section's process-vary option takes a 0 or 1 value to disable or enable the vary processing. When disabled, a response containing such a header will never be cached. When enabled, we will calculate a preliminary hash for a subset of request headers on all the incoming requests (which might come with a cpu cost) which will be used to build a secondary key for a given request (see RFC 7234#4.1). The default value is 0 (disabled).
2020-11-16 14:56:10 +00:00
# responses containing a Vary header
txreq -url "/no_vary_support"
rxresp
expect resp.status == 200
expect resp.bodylen == 57
expect resp.http.X-Cache-Hit == 0
txreq -url "/no_vary_support"
rxresp
expect resp.status == 200
expect resp.bodylen == 57
expect resp.http.X-Cache-Hit == 0
MEDIUM: cache: Add the Vary header support Calculate a preliminary secondary key for every request we see so that we can have a real secondary key if the response is cacheable and contains a manageable Vary header. The cache's ebtree is now allowed to have multiple entries with the same primary key. Two of those entries will be distinguished thanks to secondary keys stored in the cache_entry (based on hashes of a subset of their headers). When looking for an entry in the cache (cache_use), we still use the primary key (built the same way as before), but in case of match, we also need to check if the entry has a vary signature. If it has one, we need to perform an extra check based on the newly built secondary key. We will only be able to forge a response out of the cache if both the primary and secondary keys match with one of our entries. Otherwise the request will be forwarder to the server.
2020-11-16 14:56:09 +00:00
} -run
Reference in New Issue Copy Permalink