Perl LWP::UserAgent зависает на 120 секунд, по-видимому, случайным образом на заданном сервере

Я думаю, вполне вероятно, что ваша транзакция на самом деле занимает так много времени. Об этом говорится в документации для LWP::UserAgent.

[Обработчик response_data] должен возвращать значение TRUE для повторного вызова для последующих фрагментов для одного и того же запроса.

поэтому, поскольку ваш обработчик ничего не возвращает, вы отслеживаете только первый возвращенный пакет данных

Согласно вашему выводу, первые 4 КБ данных поступают за 2,2 секунды или примерно 2 КБ в секунду. Все данные имеют длину 369 КБ, поэтому вы ожидаете получить еще 92 пакета данных, а при скорости 2 КБ в секунду для передачи потребуется три минуты. Вы получите ответ через две минуты, поэтому я думаю, что ваше время разумно.

Благодаря ответу Бородина я нашел способ исправить это:

Я изменил обработчик событий response_data следующим образом:

if($res->header('Content-Length') == length($res->content)) {
    die "OK"; # Got whole data, not waiting for server to end the communication channel.
}
return 1; # In other cases make sure the handler is called for subsequent chunks

И затем, если заголовок X-Died равен OK, то игнорируйте ошибки в вызывающем.

Я знаю, что сейчас это очень старо, но недавно у меня была такая же проблема. Это происходило только тогда, когда размер незашифрованного HTTPS-ответа, включая заголовки, составлял ровно 1024 байта. Бенуа, похоже, получил ответы размером ровно 4096 байт, поэтому, возможно, число, кратное 1024, имеет значение. У меня не было контроля над сервером, поэтому я не мог создавать тестовые ответы произвольной длины и не мог воспроизвести проблему на каком-либо другом сервере. Однако появление в 1024 байтах было повторяемым.

Просматривая код LWP (v6.05), я обнаружил, что sysread запрашивает чтение 1024 байт за раз. Итак, в первый раз он возвращает все 1024 байта. Затем он немедленно вызывается во второй раз, и вместо возврата 0, указывающего, что данных больше нет, он возвращает undef, указывающий на ошибку, и устанавливает для errno значение EAGAIN, указывающее, что есть еще данные, но они еще недоступны. . Это приводит к выбору в сокете, который зависает, потому что больше данных не будет. Для тайм-аута требуется 120 секунд, после чего возвращаются те данные, которые у нас есть, что оказывается правильным результатом. Поэтому мы не получаем никаких ошибок, только большую задержку.

У меня не было достаточно удобного доступа, чтобы использовать решение Бенуа. Вместо этого мой обходной путь состоял в том, чтобы расширить код обработки HTTPS, чтобы проверить вышеописанную ситуацию и вернуть 0 вместо undef:

package LWP::Protocol::https::Socket;

sub sysread {
    my $self = shift;
    my $result = $self->SUPER::sysread(@_);
    # If we get undef back then some error occurred. If it's EAGAIN
    # then that ought to mean that there is more data to read but
    # it's not available yet. We suspect the error may be false.
    # $_[2] is the offset, so if it's defined and non-zero we have
    # some data in the buffer.
    # $_[0] is the buffer, so check it for an entire HTTP response,
    # including the headers and the body. If the length specified
    # by Content-Length is exactly the length of the body we have in
    # the buffer, then take that as being complete and return a length
    # here instead. Since it's unlikely that anything was read, the
    # buffer will not have increased in size and the result will be zero
    # (which was the expected result anyway).
    if (!defined($result) &&
        $!{EAGAIN} &&
        $_[2] &&
        $_[0] =~ /^HTTP\/\d+\.\d+\s+\d+\s+.*\s+content-length\s*:\s*(\d+).*?\r?\n\r?\n(.*)$/si &&
        length($2) == $1) {
            return length($_[0]) - $_[2]; # bufferlen - offset
    }
    return $result;
}

Алан, я получил такое же поведение в своей системе. Для контента длиной 1024, 2048, 3072 байта и т. д.

Решение этой проблемы — обновить Net::HTTP до версии 6.09 и выше.