view proxy_cache_lock_ssi.t @ 1571:1b4ceab9cb1c

Tests: fixed ssl_certificate.t with LibreSSL client. Net::SSLeay::connect() that manages TLS handshake could return unexpected error when receiving server alert, as seen in server certificate tests if it could not been selected. Typically, it returns the expected error -1, but with certain libssl implementations it can be 0, as explained below. The error is propagated from libssl's SSL_connect(), which is usually -1. In modern OpenSSL versions, it is the default error code used in the state machine returned when something went wrong with parsing TLS message header. In versions up to OpenSSL 1.0.2, with SSLv23_method() used by default, -1 is the only error code in the ssl_connect() method implementation which is used as well if receiving alert while parsing ServerHello. BoringSSL also seems to return -1. But it is not so with LibreSSL that returns zero. Previously, tests failed with client built with LibreSSL with SSLv3 removed. Here, the error is propagated directly from ssl_read_bytes() method, which is always implemented as ssl3_read_bytes() in all TLS methods. It could be also seen with OpenSSL up to 1.0.2 with non-default methods explicitly set.
author Sergey Kandaurov <pluknet@nginx.com>
date Fri, 29 May 2020 23:10:20 +0300
parents be45fa007655
children
line wrap: on
line source

#!/usr/bin/perl

# (C) Maxim Dounin

# Tests for http proxy cache lock with subrequests.

###############################################################################

use warnings;
use strict;

use Test::More;

BEGIN { use FindBin; chdir($FindBin::Bin); }

use lib 'lib';
use Test::Nginx qw/ :DEFAULT http_end /;

###############################################################################

select STDERR; $| = 1;
select STDOUT; $| = 1;

my $t = Test::Nginx->new()->has(qw/http proxy cache ssi/)
	->write_file_expand('nginx.conf', <<'EOF')->plan(2);

%%TEST_GLOBALS%%

daemon off;

events {
}

http {
    %%TEST_GLOBALS_HTTP%%

    proxy_cache_path   %%TESTDIR%%/cache  levels=1:2
                       keys_zone=NAME:1m;

    limit_req_zone $binary_remote_addr zone=one:1m rate=1r/m;

    server {
        listen       127.0.0.1:8080;
        server_name  localhost;

        location / {
            proxy_pass    http://127.0.0.1:8081;
            proxy_cache   NAME;

            proxy_cache_lock on;
            proxy_cache_lock_timeout 100ms;

            proxy_read_timeout 3s;
        }

        location = /ssi.html {
            ssi on;
        }
    }

    server {
        listen       127.0.0.1:8081;
        server_name  localhost;
        limit_req zone=one burst=5;
    }

}

EOF

$t->write_file('ssi.html',
	'<!--#include virtual="/active" -->' .
	'<!--#include virtual="/locked" -->' .
	'end'
);

$t->write_file('active', 'active');
$t->write_file('locked', 'locked');

$t->run();

###############################################################################

# problem: if proxy cache lock wakeup happens in an inactive
# subrequest, just a connection write event may not trigger any
# further work

# main request -> subrequest /active (waiting for a backend),
#              -> subrequest /locked (locked by another request)

# this doesn't result in an infinite timeout as second subrequest
# is woken up by the postpone filter once first subrequest completes,
# but this is suboptimal behaviour

http_get('/charge');
my $start = time();

my $s = http_get('/locked', start => 1);
select undef, undef, undef, 0.2;

like(http_get('/ssi.html'), qr/end/, 'cache lock ssi');
http_end($s);
cmp_ok(time() - $start, '<=', 5, 'parallel execution after lock timeout');

###############################################################################