Re: often mod_proxy cache revalidates
On Mon, Jun 21, 2021 at 03:06:38PM +0200, pgajdos wrote: > 8< > mkdir -p /tmp/apache-rex/mod_proxy-cache/htdocs-backend > echo 'Backend for reverse' > > /tmp/apache-rex/mod_proxy-cache/htdocs-backend/index.html > > sleep 1 > > echo "[2] forward proxy with cache" > for i in $(seq 1 10); do > curl -s -v --proxy http://localhost:60083/ http://localhost:60081/ 2>&1 | > grep 'X-Cache' > sleep 0.1 > done > >8 > > gives: > > $ sh run.sh > [2] forward proxy with cache > < X-Cache: MISS from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > < X-Cache: REVALIDATE from test > $ > > Altering (or touching) the the index file is essential, as well as the > sleep afterwards. In other words, when I remove the sleep, I get, without restaring httpd: [2] forward proxy with cache < X-Cache: MISS from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test < X-Cache: HIT from test Furthermore: When I add the sleep now and do not restart httpd, I get the same output, 9xHIT. I need to restart httpd first to get 9xREVALIDATE again. Petr -- Have a lot of fun!
Re: often mod_proxy cache revalidates
Hi,
how to more easily reproduce: with following configuration file,
located e. g. in /tmp/apache-rex/mod_proxy-cache/httpd.conf:
On Wed, Jun 16, 2021 at 01:01:59PM +0200, pgajdos wrote:
> --8<
> ServerName test
> User abuild
> Group abuild
> Listen 60080
> PidFile /tmp/apache-rex/mod_proxy-cache/pid
> ErrorLog /tmp/apache-rex/mod_proxy-cache/error_log
> LoadModule auth_basic_module /usr/lib64/apache2-prefork/mod_auth_basic.so
> LoadModule dir_module /usr/lib64/apache2-prefork/mod_dir.so
> LoadModule authz_host_module /usr/lib64/apache2-prefork/mod_authz_host.so
> LoadModule proxy_module /usr/lib64/apache2-prefork/mod_proxy.so
> LoadModule proxy_http_module /usr/lib64/apache2-prefork/mod_proxy_http.so
> LoadModule cache_module /usr/lib64/apache2-prefork/mod_cache.so
> LoadModule log_config_module /usr/lib64/apache2-prefork/mod_log_config.so
> LoadModule authz_core_module /usr/lib64/apache2-prefork/mod_authz_core.so
> LoadModule cache_socache_module
> /usr/lib64/apache2-prefork/mod_cache_socache.so
> LoadModule socache_shmcb_module
> /usr/lib64/apache2-prefork/mod_socache_shmcb.so
> DocumentRoot /tmp/apache-rex/mod_proxy-cache/htdocs
> DirectoryIndex index.html
>
> ### example configuration
>
> LogFormat "%s %{cache-status}e" cache_format
>
> Listen 60081
>
> ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-backend"
> DocumentRoot "/tmp/apache-rex/mod_proxy-cache/htdocs-backend"
>
> Require local
>
>
>
> Listen 60082
>
> ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-reverse-proxy"
>
>
> ProxyPass "http://localhost:60081/;
>
>
> CacheSocache shmcb
> CacheSocacheMaxSize 102400
> CacheEnable socache "/"
>
> CacheHeader on
>
> CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-uncached.log"
> cache_format env=cache-miss
> CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-cached.log"
> cache_format env=cache-hit
> CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-revalidated.log"
> cache_format env=cache-revalidate
>
>
> Listen 60083
>
> ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-forward-proxy"
>
> ProxyRequests On
>
> Require local
>
>
> CacheSocache shmcb
> CacheSocacheMaxSize 102400
> # http://httpd.apache.org/docs/current/mod/mod_cache.html#cacheenable
> CacheEnable socache http://localhost:60081/
>
> CacheHeader on
>
> CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-uncached.log"
> cache_format env=cache-miss
> CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-cached.log"
> cache_format env=cache-hit
> CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-revalidated.log"
> cache_format env=cache-revalidate
>
> -->8
following script:
8<
mkdir -p /tmp/apache-rex/mod_proxy-cache/htdocs-backend
echo 'Backend for reverse' >
/tmp/apache-rex/mod_proxy-cache/htdocs-backend/index.html
sleep 1
echo "[2] forward proxy with cache"
for i in $(seq 1 10); do
curl -s -v --proxy http://localhost:60083/ http://localhost:60081/ 2>&1 |
grep 'X-Cache'
sleep 0.1
done
>8
gives:
$ sh run.sh
[2] forward proxy with cache
< X-Cache: MISS from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
$
Altering (or touching) the the index file is essential, as well as the
sleep afterwards.
Petr
--
Have a lot of fun!
often mod_proxy cache revalidates
Hi,
from 2.4.48 on, mod_proxy-cache example [1] begins to fail for me.
Unfortunately I can not manage to expose this issue outside
apache-rex framework sofar. With 2.4.46, I can not see this at all.
$ git clone https://github.com/pgajdos/apache-rex.git
$ cd apache-rex
$ ./run-rex mod_proxy-cache
[..]
[1] reverse proxy with cache
< X-Cache: MISS from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
1 misses, 0 revalidates and 9 hits
[2] forward proxy with cache
< X-Cache: MISS from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
< X-Cache: REVALIDATE from test
1 misses, 9 revalidates and 0 hits
Example FAILED (subexample #2):
[..]
$
Former behavior for 2.4.46:
[1] reverse proxy with cache
< X-Cache: MISS from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
1 misses, 0 revalidates and 9 hits
[2] forward proxy with cache
< X-Cache: MISS from test
< X-Cache: REVALIDATE from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
< X-Cache: HIT from test
1 misses, 1 revalidates and 8 hits
Roughly: the example config (/tmp/apache-rex/mod_proxy-cache/httpd.conf) looks
like:
--8<
ServerName test
User abuild
Group abuild
Listen 60080
PidFile /tmp/apache-rex/mod_proxy-cache/pid
ErrorLog /tmp/apache-rex/mod_proxy-cache/error_log
LoadModule auth_basic_module /usr/lib64/apache2-prefork/mod_auth_basic.so
LoadModule dir_module /usr/lib64/apache2-prefork/mod_dir.so
LoadModule authz_host_module /usr/lib64/apache2-prefork/mod_authz_host.so
LoadModule proxy_module /usr/lib64/apache2-prefork/mod_proxy.so
LoadModule proxy_http_module /usr/lib64/apache2-prefork/mod_proxy_http.so
LoadModule cache_module /usr/lib64/apache2-prefork/mod_cache.so
LoadModule log_config_module /usr/lib64/apache2-prefork/mod_log_config.so
LoadModule authz_core_module /usr/lib64/apache2-prefork/mod_authz_core.so
LoadModule cache_socache_module /usr/lib64/apache2-prefork/mod_cache_socache.so
LoadModule socache_shmcb_module /usr/lib64/apache2-prefork/mod_socache_shmcb.so
DocumentRoot /tmp/apache-rex/mod_proxy-cache/htdocs
DirectoryIndex index.html
### example configuration
LogFormat "%s %{cache-status}e" cache_format
Listen 60081
ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-backend"
DocumentRoot "/tmp/apache-rex/mod_proxy-cache/htdocs-backend"
Require local
Listen 60082
ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-reverse-proxy"
ProxyPass "http://localhost:60081/;
CacheSocache shmcb
CacheSocacheMaxSize 102400
CacheEnable socache "/"
CacheHeader on
CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-uncached.log"
cache_format env=cache-miss
CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-cached.log"
cache_format env=cache-hit
CustomLog "/tmp/apache-rex/mod_proxy-cache/reverse-proxy-revalidated.log"
cache_format env=cache-revalidate
Listen 60083
ErrorLog "/tmp/apache-rex/mod_proxy-cache/error_log-forward-proxy"
ProxyRequests On
Require local
CacheSocache shmcb
CacheSocacheMaxSize 102400
# http://httpd.apache.org/docs/current/mod/mod_cache.html#cacheenable
CacheEnable socache http://localhost:60081/
CacheHeader on
CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-uncached.log"
cache_format env=cache-miss
CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-cached.log"
cache_format env=cache-hit
CustomLog "/tmp/apache-rex/mod_proxy-cache/forward-proxy-revalidated.log"
cache_format env=cache-revalidate
-->8
And the script runs 10 requests on the server:
for i in $(seq 1 10); do
curl -s -v --proxy http://localhost:60083/ http://localhost:60081/ 2>&1 |
grep 'X-Cache'
sleep 0.1
done
And again, I cannot reproduce for example with httpd run with
fx. -f /tmp/apache-rex/mod_proxy-cache/httpd.conf and running requests
manually. I will try harder, I just want to know first whether this is
something known or whether I have something completely wrong in the
configuration.
Thanks for your attention,
Petr
[1] https://github.com/pgajdos/apache-rex/tree/master/mod_proxy-cache
--
Have a lot of fun!
SSLFIPS on/off
Hello,
I have a question regarding the logic around SSLFIPS on/off. After
https://svn.apache.org/viewvc?view=revision=1853197
I think SSLFIPS off will not work as expected.
#ifdef HAVE_FIPS
if (sc->fips) {
if (!FIPS_mode()) {
if (FIPS_mode_set(1)) {
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s, APLOGNO(01884)
"Operating in SSL FIPS mode");
apr_pool_cleanup_register(p, NULL, modssl_fips_cleanup,
apr_pool_cleanup_null);
}
else {
ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(01885)
"FIPS mode failed");
ssl_log_ssl_error(SSLLOG_MARK, APLOG_EMERG, s);
return ssl_die(s);
}
}
}
else {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01886)
"SSL FIPS mode disabled");
}
#endif
In case sc->fips is FALSE (SSLFIPS off or not set), the
FIPS_mode_set() is not called at all and the fips mode is untouched.
If I understand correctly, it can be ON as it is on my system when a
binary starts up.
Question also is, whether the FIPS mode should not stand untouched
when SSLFIPS is not specified at all (not intend to turning it off).
Perhaps even more basic concern, what is actually the purpose
(usecase) or SSLFIPS directive? In other words, in case you have a
FIPS system, why you would like to disable it in httpd?
Unfortunately I do not know much about FIPS, so perhaps I missed
something basic but important, apologize in advance :).
Bye,
Petr
--
Have a lot of fun!
Re: Fwd: t/modules/{brotli,deflate}.t: handle the case < 2.4.42
Hi! On Thu, Dec 19, 2019 at 10:32:11PM +0100, Marion & Christophe JAILLET wrote: >In other word, what is the "semantic" behind the test framework? > - Testing against regression only? (in this case including Petr's >patch makes sense to me) - or - > - Checking that the behavior is correct (in this case, I'm not fan >of "hiding" things that are known to fail. A failure would mean: "you >should upgrade to have this fixed") Both works for me, in case of #2, I will just fork testsuite for each new code stream and eventually backport needed tests for upcomming bug fixes. I just need to know your preference. Have nice Christmas, Petr -- Have a lot of fun!
Re: [testsuite] MergeSlashes was added recently
On Thu, Mar 21, 2019 at 07:47:14AM -0400, Eric Covener wrote: > On Thu, Mar 21, 2019 at 5:36 AM pgajdos wrote: > > > > Hello, > > > > please see the proposed patch in the attachement. > > Thanks Petr, applied in 1855981 Thanks for both! Petr
Re: [testsuite] negotiation.t: fails for older versions
On Tue, Jan 29, 2019 at 11:15:04AM +0100, pgajdos wrote: > Hello, > > I propose following patch, as PR39730 was fixed recently. What do you think about the patch? Should it be amended somehow? Thanks! Petr
[testsuite] MergeSlashes was added recently
Hello,
please see the proposed patch in the attachement.
Petr
Index: httpd-framework/t/apache/mergeslashes.t
===
--- httpd-framework.orig/t/apache/mergeslashes.t 2019-03-21 08:49:48.086794262 +0100
+++ httpd-framework/t/apache/mergeslashes.t 2019-03-21 10:04:58.800351025 +0100
@@ -21,7 +21,7 @@ my @test_cases = (
[ "GET /authz_core/a//b/c/index.html HTTP/1.1\r\nHost: merge-disabled\r\n\r\n" => 403, "a// matches locationmatch"],
[ "GET /authz_core/a/b/c//index.html HTTP/1.1\r\nHost: merge-disabled\r\n\r\n" => 200, "c// doesn't match locationmatch"],
);
-plan tests => scalar(@test_cases), need_min_apache_version('2.5.1');
+plan tests => scalar(@test_cases), need_min_apache_version('2.4.39');
foreach my $t (@test_cases) {
Index: httpd-framework/t/conf/core.conf.in
===
--- httpd-framework.orig/t/conf/core.conf.in 2019-03-21 08:49:48.578796993 +0100
+++ httpd-framework/t/conf/core.conf.in 2019-03-21 10:06:04.708729107 +0100
@@ -17,26 +17,28 @@
# MergeSlashes
-
- ServerName merge-default
-
- require all granted
-
-
- require all denied
-
-
-
- ServerName merge-disabled
- MergeSlashes OFF
-
- require all granted
-
-
- require all denied
-
-
- require all denied
-
-
+= 2.4.39>
+
+ ServerName merge-default
+
+ require all granted
+
+
+ require all denied
+
+
+
+ ServerName merge-disabled
+ MergeSlashes OFF
+
+ require all granted
+
+
+ require all denied
+
+
+ require all denied
+
+
+
Re: [testsuite] buffer.t: fails randomly
On Tue, Jan 29, 2019 at 09:48:10PM +0100, Christophe JAILLET wrote: > Le 29/01/2019 à 14:59, pgajdos a écrit : > > 4, 8 and 12 subtests of buffer.t are randomly failing for me. I have > Hi, there has been some discussion about this new test added in r1841508 > > See > https://marc.info/?t=15395168252=1=4 > and > https://github.com/libwww-perl/libwww-perl/issues/299 Aha, thanks for the pointers. Petr
[testsuite] buffer.t: fails randomly
Hello, tested with 2.4.37 and 2.4.38. 4, 8 and 12 subtests of buffer.t are randomly failing for me. I have already seen to fail zero, one, two or all of them. When none fails, the test is done in very few seconds (including initialization of t/TEST). $r->code of the failing subtest is: 200 $r->content of the failing test is for example: foofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoofoo ... foofo 408 Request Timeout Request Timeout Server timeout waiting for the HTTP request from the client. where ' ... ' stands for lot of 'foo', as expected. How should I debug? Petr
[testsuite] negotiation.t: fails for older versions
Hello,
I propose following patch, as PR39730 was fixed recently.
--- t/modules/negotiation.t.orig2019-01-29 07:49:18.495899602 +
+++ t/modules/negotiation.t 2019-01-29 07:52:38.428960368 +
@@ -8,7 +8,11 @@ use Apache::TestUtil;
## mod_negotiation test (see extra.conf.in)
my ($en, $fr, $de, $fu, $bu, $zh) = qw(en fr de fu bu zh-TW);
-my @language = ($en, $fr, $de, $fu, $zh);
+
+my @language = ($en, $fr, $de, $fu);
+if (have_min_apache_version("2.4.38")) {
+ push @language, $zh;
+}
my @ct_tests = (
# [ Accept header, Expected response ]
Petr
Re: 2.4.38
On Fri, Nov 09, 2018 at 02:15:07PM +1000, Noel Butler wrote: > even those distro package maintainers get sick to F'n death of it after > a while and skip updates. I do not see any reason I should get distinguished by it. Frequent version updates are even better for me. Petr
Re: alias.t/extra.conf.in change 1829008
On Tue, Aug 21, 2018 at 08:51:56PM +0200, Marion & Christophe JAILLET wrote: > > One thing I noticed is insufficient version checking of httpd version, > Well, it is sometimes hard to figure out when a given feature or directive > has been added. Especially when tests are added a long time afterwards. > Well, it is not that hard, but it is time consuming and honestly, I don't > really focus on old releases compatibility. > And as you say, 2.2 is no more supported by us, so... Yes, this was actually implicit question if you want to see such patches I had sent you or you rather want to get rid of 2.2 ifversions in the testsuite. Thanks for replying, again implicitly ;). > Having more test is always needed and we consider that some work should be > needed in this area. > Contributions welcome :) Noted. Petr
