Sporadic timeouts on https://google.com with HTTP/3 on Arch Linux

From: Jicea via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 26 Jul 2024 15:22:17 +0000

Hi everybody,

I've sporadic timeout issues on testing HEAD requests against https://google.com with HTTP/3, on Arch Linux.

My environment:

- GitHub action with ubuntu/latest image
- I'm using a archlinux/latest image for the test, so this is a Docker in Docker setup (GitHub has no Arch Linux runner)
- On archlinux/latest, curl version is 8.9.0 (from pacman), using OpenSSL 3.3.1 and HTTP/3 is activated.

See .github/workflow image here: https://github.com/jcamiel/curlhttp3/blob/main/.github/workflows/test.yml
Sample project is here https://github.com/jcamiel/curlhttp3
Example of test failure: https://github.com/jcamiel/curlhttp3/actions/runs/10113188862/job/27968973290

My C sample is rather simple:

#include <curl/curl.h>

static CURLcode sslctx_function(CURL *curl, void *sslctx, void *parm) {
    return CURLE_OK;
}

int main(int argc, char *argv[]) {
    CURLcode ret;
    CURL *hnd;

    char *data = "";

    hnd = curl_easy_init();

    curl_easy_reset(hnd);

    curl_easy_setopt(hnd, CURLOPT_URL, "https://google.com");
    curl_easy_setopt(hnd, CURLOPT_TIMEOUT, 20L);
    curl_easy_setopt(hnd, CURLOPT_NOPROGRESS, 1L);
    curl_easy_setopt(hnd, CURLOPT_NOBODY, 1L);
    curl_easy_setopt(hnd, CURLOPT_MAXREDIRS, 50L);
    curl_easy_setopt(hnd, CURLOPT_HTTP_VERSION, (long)CURL_HTTP_VERSION_3);
    curl_easy_setopt(hnd, CURLOPT_VERBOSE, 1L);
    curl_easy_setopt(hnd, CURLOPT_SSL_CTX_FUNCTION, *sslctx_function);
    curl_easy_setopt(hnd, CURLOPT_SSL_CTX_DATA, data);
    ret = curl_easy_perform(hnd);

    curl_easy_cleanup(hnd);

    return (int)ret;
}

When I run the sample, I have sporadic timeout issues, for instance:

Request #1:
  * Host google.com:443 was resolved.
  * IPv6: 2607:f8b0:4009:818::200e
  * IPv4: 142.250.191.142
  * Trying 142.250.191.142:443...
  * CAfile: /etc/ssl/certs/ca-certificates.crt
  * CApath: none
  * Server certificate:
  * subject: CN=*.google.com
  * start date: Jul 1 06:35:43 2024 GMT
  * expire date: Sep 23 06:35:42 2024 GMT
  * subjectAltName: host "google.com" matched cert's "google.com"
  * issuer: C=US; O=Google Trust Services; CN=WR2
  * SSL certificate verify ok.
  * Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
  * Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
  * Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
  * Connected to google.com (142.250.191.142) port 443
  * using HTTP/3
  * [HTTP/3] [0] OPENED stream for https://google.com/
  * [HTTP/3] [0] [:method: HEAD]
  * [HTTP/3] [0] [:scheme: https]
  * [HTTP/3] [0] [:authority: google.com]
  * [HTTP/3] [0] [:path: /]
  * [HTTP/3] [0] [accept: */*]
> HEAD / HTTP/3
  Host: google.com
  Accept: */*

  * Request completely sent off
  * Operation timed out after 20001 milliseconds with 0 bytes received
  * Connection #0 to host google.com left intact


For context, I'm tracking this issue raised by the integration tests for Hurl project (https://github.com/Orange-OpenSource/hurl). Hurl is a CLI tool that relies on libcurl for HTTP exchanges (and we're very happy with that!!)
I don't remember having this issue with --http2 nor --http1.1, and start seeing this when Arch Linux curl package has been updated with HTTP/3

In the C sample, I've set up a dummy callback here:

    curl_easy_setopt(hnd, CURLOPT_SSL_CTX_FUNCTION, *sslctx_function);
    curl_easy_setopt(hnd, CURLOPT_SSL_CTX_DATA, data);

The reason is that I've the impression that I don't have the timeout issue when I'm not calling CURLOPT_SSL_CTX_FUNCTION and CURLOPT_SSL_CTX_DATA (I'm doing more tests now)
Another point: the test setup is Docker In Docker within GitHub infra. We've tried to reproduce these timeout issues on a real Arch Linux runner and haven't seen a single timeout (while trying a lot).

I really struggle to see what can happen here. I would be happy if someone could at least confirm that there is a problem and that I'm not crazy.

If somebody has any advice about how to approach this debugging, I'll be happy to test things. My next plan is to try to add more traces with curl_global_trace

Thanks you all,

Jean-Christophe









Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2024-07-26