very long urls and openssl and curl_easy_perform fails

[adamse]

I did this

This test program fails with CURLE_SEND_ERROR if the https url in the file in argv[1] is longer than ~u16 max.

CURLE_SEND_ERROR curl_easy_perform() failed: Failed sending data to the peer
SSL_write() error: error:0A00010F:SSL routines::bad length

(Please excuse the C++)

#include <iostream>
#include <fstream>
#include <string>
#include <cassert>

#include <curl/curl.h>

size_t WriteCallback(void* contents, size_t size, size_t nmemb, void* userp) {
    ((std::string*)userp)->append((char*)contents, size * nmemb);
    return size * nmemb;
}

int main(int argc, char* argv[]) {
    if (argc < 2) {
        std::cerr << "Usage: " << argv[0] << " <url_file>" << std::endl;
        return 1;
    }

    std::ifstream urlFile(argv[1]);
    if (!urlFile.is_open()) {
        std::cerr << "Failed to open file: " << argv[1] << std::endl;
        return 1;
    }

    std::string url;
    std::getline(urlFile, url);
    urlFile.close();

    CURL* curl;
    CURLcode res;
    std::string response;

    curl = curl_easy_init();
    assert(curl && "Failed to initialize CURL.");

    char* err = (char*)malloc(CURL_ERROR_SIZE);
    assert(err && "Failed to alloc err buf");

    curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
    curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, WriteCallback);
    curl_easy_setopt(curl, CURLOPT_WRITEDATA, &response);
    curl_easy_setopt(curl, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NATIVE_CA);
    curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, err);

    res = curl_easy_perform(curl);
    if (res == CURLE_SEND_ERROR) {
        std::cerr << "CURLE_SEND_ERROR curl_easy_perform() failed: " << curl_easy_strerror(res) << std::endl;
        std::cerr << err << std::endl;
    } else if (res != CURLE_OK) {
        std::cerr << "curl_easy_perform() failed: " << curl_easy_strerror(res) << std::endl;
        std::cerr << std::string(err) << std::endl;
    } else {
        std::cout << "Successful" << std::endl;
    }

    curl_easy_cleanup(curl);
    free(err);

    return 0;
}

I think this is an issue with how openssl SSL_write is used, where it errors with SSL_ERROR_WANT_WRITE and expects to be presented with the same buffer again until it succeeds, but curl's openssl integration does something that is not exactly that.

I tried a hacky workaround to confirm if this could be the issue, and it seems to work.

diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c
index 6ded5f3c0..712c70657 100644
--- a/lib/vtls/openssl.c
+++ b/lib/vtls/openssl.c
@@ -5086,9 +5086,22 @@ static ssize_t ossl_send(struct Curl_cfilter *cf,
   memlen = (len > (size_t)INT_MAX) ? INT_MAX : (int)len;
   rc = SSL_write(octx->ssl, mem, memlen);

-  if(rc <= 0) {
+  while (rc <= 0) {
     err = SSL_get_error(octx->ssl, rc);
+    if (err == SSL_ERROR_WANT_WRITE) {
+      // HACK: when erroring with SSL_ERROR_WANT_WRITE openssl wants you to
+      // present the same buffer again once the underlying socket is ready.
+      // Here we just try in a loop instead of polling the socket.
+      //
+      // This works around an issue with curl and https and _very_ long urls
+      // (u16 max seems to be the breaking point for the size of the headers).
+      rc = SSL_write(octx->ssl, mem, memlen);
+    } else {
+      break;
+    }
+  }

+  if(rc <= 0) {
     switch(err) {
     case SSL_ERROR_WANT_READ:
       connssl->io_need = CURL_SSL_IO_NEED_RECV;

I expected the following

No response

curl/libcurl version

libcurl 8.12.1 & libcurl 8.15.0
openssl 3.4.1

operating system

Windows 10

[icing]

@adamse, thanks for the report. I added tests for super-sized URLs in #18129:

With url lenghts less than 64KB, all protocols work and behave the same. When crossing 64KB, things start to differ:

• http/1.1: works the same, Apache httpd gives HTTP response 414
• h2: fails sending the request due to protocol limitations that cannot send headers that do not fit in a frame
• h3: gives HTTP response 431 from nghttpx (this might vary with other servers)

So, in these tests, curl works just as intended. The h2 limitations are just inherent to the protocol.

Now, in your failures, was HTTP/2 used?

[adamse]

This is http/1.1 over TLS (using openssl).

[icing]

We are setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER when available. That should work with the OpenSSL 3.4.1 you are using. Trying to reproduce here...

[adamse]

(My original url was 135K but I bisected the url to around 64K)

[adamse]

We are setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER when available

I agree, I can see that line being executed in the debugger.

[icing]

I've simulated partial/blocked writes and my tests run just fine with OpenSSL 3.4.1.

Since I am unable to reproduce, it would help if you could produce a trace, using curl_global_trace("all") and a DEBUGFUNCTION. Also, a curl_global_init() would be nice, just to be sure.

[adamse]

Part of the trace:

== Info: using HTTP/1.x
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> -1, err=81
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> -1, err=81
== Info: SSL_write() error: error:0A00010F:SSL routines::bad length
== Info: [WRITE] cw-out done

(DEBUGFUNCTION like the example on https://curl.se/libcurl/c/CURLOPT_DEBUGFUNCTION.html (except the dump part, with dump I don't see the error, I'm guessing dumping the bytes makes it slow enough that we don't hit this SSL_write error)).

I also added curl_global_init(CURL_GLOBAL_ALL);.

[icing]

Thanks. Here is what I see using curl 8.12.1 and OpenSSL 3.4.1:

13:24:44.070259 [0-0] * using HTTP/1.x
13:24:44.070328 [0-0] * STATE: CONNECTING => PROTOCONNECT handle 0x7fede501b008; line 2447
13:24:44.070399 [0-0] * STATE: PROTOCONNECT => DO handle 0x7fede501b008; line 2477
13:24:44.073269 [0-0] * sending last upload chunk of 65636 bytes
13:24:44.073350 [0-0] } [5 bytes data]
13:24:44.073472 [0-0] * [TCP] send(len=16406) -> 16406, err=0
13:24:44.073544 [0-0] * [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
13:24:44.073617 [0-0] } [5 bytes data]
13:24:44.073733 [0-0] * [TCP] send(len=16406) -> 16406, err=0
13:24:44.073804 [0-0] * [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
13:24:44.073876 [0-0] } [5 bytes data]
13:24:44.073985 [0-0] * [TCP] send(len=16406) SIMULATE EWOULDBLOCK
13:24:44.074053 [0-0] * [SSL] ossl_bio_cf_out_write(len=16406) -> -1, err=81
13:24:44.074124 [0-0] * Curl_xfer_send(len=65636, eos=1) -> 0, 0
13:24:44.074237 [0-0] * [TCP] send(len=16406) SIMULATE EWOULDBLOCK
13:24:44.074307 [0-0] * [SSL] ossl_bio_cf_out_write(len=16406) -> -1, err=81
13:24:44.074375 [0-0] * Curl_xfer_send(len=65536, eos=0) -> 0, 0
13:24:44.074443 [0-0] * Curl_req_flush(len=65636) -> EAGAIN

This looks like exactly the same network condition, only for me OpenSSL does not report a bad length.

[adamse]

Ok, that's interesting...

Some ad-hoc logging in ossl_send

printf("SSL_write(%p, %p, %zu)\n", octx->ssl, mem, memlen);

== Info: using HTTP/1.x
SSL_write(0x22e20e57130, 0x22e21237350, 137998)
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> 16406, err=0
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> 16406, err=0
== Info: [TCP] send(len=16406) -> -1, err=81
== Info: [SSL] ossl_bio_cf_out_write(len=16406) -> -1, err=81
SSL_write(0x22e20e57130, 0x22e21277380, 65536)
== Info: SSL_write() error: error:0A00010F:SSL routines::bad length
== Info: [WRITE] cw-out done

so, I go back to the initial thought: SSL_write doesn't get the same buf (which in curl's case might be moved) and length after SSL_ERROR_WANT_WRITE...