OSSL_HTTP_TRANSFER(3SSL)

📦
version 4.0.3 · 13 versions
, in ubuntu stonking

Hey bestie! Welcome to the OSSL_HTTP_TRANSFER(3SSL) man page. This is part 1 of 3, and we're about to get into the HTTP client high-level functions from OpenSSL. No cap, these functions are the main character energy for making HTTP requests. Let's get into it! 💅

✨ NAME ✨

okay so these are the OpenSSL HTTP client high-level functions. The whole squad is:

  • OSSL_HTTP_open
  • OSSL_HTTP_bio_cb_t
  • OSSL_HTTP_proxy_connect
  • OSSL_HTTP_set1_request
  • OSSL_HTTP_exchange
  • OSSL_HTTP_get
  • OSSL_HTTP_transfer
  • OSSL_HTTP_close

— and they're all about HTTP client high-level functions. Periodt. 💖

🌈 SYNOPSIS 🌈

here's the code, bestie. The include and the prototypes are exactly as they should be, so don't come for me if you change a single character:

#include <openssl/http.h>

typedef BIO *(*OSSL_HTTP_bio_cb_t)(BIO *bio, void *arg,
                                   int connect, int detail);
OSSL_HTTP_REQ_CTX *OSSL_HTTP_open(const char *server, const char *port,
                                  const char *proxy, const char *no_proxy,
                                  int use_ssl, BIO *bio, BIO *rbio,
                                  OSSL_HTTP_bio_cb_t bio_update_fn, void *arg,
                                  int buf_size, int overall_timeout);
int OSSL_HTTP_proxy_connect(BIO *bio, const char *server, const char *port,
                            const char *proxyuser, const char *proxypass,
                            int timeout, BIO *bio_err, const char *prog);
int OSSL_HTTP_set1_request(OSSL_HTTP_REQ_CTX *rctx, const char *path,
                           const STACK_OF(CONF_VALUE) *headers,
                           const char *content_type, BIO *req,
                           const char *expected_content_type, int expect_asn1,
                           size_t max_resp_len, int timeout, int keep_alive);
BIO *OSSL_HTTP_exchange(OSSL_HTTP_REQ_CTX *rctx, char **redirection_url);
BIO *OSSL_HTTP_get(const char *url, const char *proxy, const char *no_proxy,
                   BIO *bio, BIO *rbio,
                   OSSL_HTTP_bio_cb_t bio_update_fn, void *arg,
                   int buf_size, const STACK_OF(CONF_VALUE) *headers,
                   const char *expected_content_type, int expect_asn1,
                   size_t max_resp_len, int timeout);
BIO *OSSL_HTTP_transfer(OSSL_HTTP_REQ_CTX **prctx,
                        const char *server, const char *port,
                        const char *path, int use_ssl,
                        const char *proxy, const char *no_proxy,
                        BIO *bio, BIO *rbio,
                        OSSL_HTTP_bio_cb_t bio_update_fn, void *arg,
                        int buf_size, const STACK_OF(CONF_VALUE) *headers,
                        const char *content_type, BIO *req,
                        const char *expected_content_type, int expect_asn1,
                        size_t max_resp_len, int timeout, int keep_alive);
int OSSL_HTTP_close(OSSL_HTTP_REQ_CTX *rctx, int ok);

that's the whole synopsis. Lowkey iconic. ✨

✨ DESCRIPTION ✨

So bestie, gather round 💖. OSSL_HTTP_open() kicks off an HTTP session — and it's giving very flexible queen energy, because it can do this in two whole ways. It uses the bio argument if that's not NULL, or else it goes out and connects to a given server, optionally via a proxy. Pick your fighter 🎀.

Usually the OpenSSL build supports sockets, and in that case the bio parameter is NULL 🫶. When that happens, rbio has to be NULL too and server must be non-NULL, no negotiating. The function spins up a network BIO internally, using BIO_new_connect(3), to connect to the given server and the optionally given port, defaulting to 80 for HTTP or 443 for HTTPS. Then that internal BIO gets used for setting up the connection and for exchanging one or more request-and-response rounds. Iconic multi-tasking, honestly 👑.

If bio is given and rbio is NULL, then that bio gets used instead. And if both bio and rbio are given (which could be memory BIOs, for instance), then no explicit connection gets set up at all — instead bio is used for writing requests and rbio for reading responses. Heads up though: as soon as the client has flushed bio, the server must be ready to hand over a response or signal a waiting condition via rbio. No ghosting allowed 💀.

If bio is given, it is an error to provide non-NULL proxy or no_proxy arguments 🙈 — while server and port arguments may be given, to support diagnostic output. Real lowkey-informational-only vibe.

If bio is NULL, the optional proxy parameter can be used to set an HTTP(S) proxy to use (unless it gets overridden by "no_proxy" settings, rude). If TLS is not used, this defaults to the environment variable "http_proxy" if set, else "HTTP_PROXY". If use_ssl != 0 it defaults to "https_proxy" if set, else "HTTPS_PROXY". An empty proxy string "" forbids using a proxy — that's the "leave me alone please" option 🌸. Otherwise, the format is:

[http[s]://][userinfo@]host[:port][/path][?query][#fragment]

…where any userinfo, path, query, and fragment given is just ignored (mid, honestly 🍓). If the host string is an IPv6 address, it must be wrapped in [ and ] — non-negotiable, bestie. The default proxy port number is 80, or 443 in case "https:" is given. The HTTP client functions connect via the given proxy unless the server shows up in the optional list no_proxy of proxy hostnames or IP addresses separated by "," and/or whitespace (if not NULL; the default is the environment variable "no_proxy" if set, else "NO_PROXY"). Proxying plain HTTP is supported directly, while using a proxy for HTTPS connections requires a suitable callback function, such as OSSL_HTTP_proxy_connect(), described a lil bit below ⭐.

If use_ssl is nonzero, a TLS connection is requested and the bio_update_fn parameter must be provided. No exceptions, periodt 💅.

The bio_update_fn parameter — optional when use_ssl is 0 — may be used to modify the connection BIO used by the HTTP client, but it cannot be used when both bio and rbio are given. bio_update_fn is a BIO connect/disconnect callback function with this prototype:

BIO *(*OSSL_HTTP_bio_cb_t)(BIO *bio, void *arg, int connect, int detail)

The callback function may modify the BIO handed to it in the bio argument, and while doing so it may use an optional custom defined argument arg, which can for instance point to an SSL_CTX structure. During connection establishment — right after BIO_do_connect_retry() gets called — the callback function is invoked with the connect argument being 1 and detail being 1 if use_ssl is nonzero (i.e., HTTPS is requested), else 0. On disconnect, connect is 0 and detail is 1 if no error occurred, else 0. For instance, on connect the callback may push an SSL BIO to implement HTTPS; after disconnect it may do some diagnostic output and pop-and-free the SSL BIO 🧚. Very main character behavior.

The callback function must return either the potentially modified BIO bio or NULL to indicate failure — and if it's failing, it should not modify the BIO at all. Respect the contract, bestie 🫶.

Here's a simple example that supports TLS connections (but not via a proxy):

BIO *http_tls_cb(BIO *bio, void *arg, int connect, int detail)
{
    if (connect && detail) { /* connecting with TLS */
        SSL_CTX *ctx = (SSL_CTX *)arg;
        BIO *sbio = BIO_new_ssl(ctx, 1);

        bio = sbio != NULL ? BIO_push(sbio, bio) : NULL;
    } else if (!connect) { /* disconnecting */
        BIO *hbio;

        if (!detail) { /* an error has occurred */
            /* optionally add diagnostics here */
        }
        BIO_ssl_shutdown(bio);
        hbio = BIO_pop(bio);
        BIO_free(bio); /* SSL BIO */
        bio = hbio;
    }
    return bio;
}

After disconnect the modified BIO will be deallocated using BIO_free_all(). The optional callback function argument arg is not consumed, so it must be freed by the caller when it's not needed any more. Don't forget, or that's a leak bestie 😭.

The buf_size parameter specifies the response header maximum line length. A value <= 0 means that the OSSL_HTTP_DEFAULT_MAX_LINE_LEN (4KiB) is used. buf_size is also used as the number of content bytes that are read at a time. Multitasking parameter, we love her ✨.

If the overall_timeout parameter is > 0 this indicates the maximum number of seconds the overall HTTP transfer (i.e., connection setup if needed, sending requests, and receiving responses) is allowed to take until completion. A value <= 0 enables waiting indefinitely, i.e., no timeout. Cue the "I have all the time in the world" energy 🦋.

OSSL_HTTP_proxy_connect() may be used by an above BIO connect callback function to set up an SSL/TLS connection via an HTTPS proxy. It promotes the given BIO bio — representing a connection pre-established with a TLS proxy using the HTTP CONNECT method — optionally using proxy client credentials proxyuser and proxypass, to connect with TLS protection ultimately to server and port 🔥. If the port argument is NULL or the empty string it defaults to "443". The server and port arguments must not contain CR or LF characters — say it with me, no CR, no LF 🙅. If the timeout parameter is > 0 this indicates the maximum number of seconds the connection setup is allowed to take. A value <= 0 enables waiting indefinitely, i.e., no timeout. Since this function is typically called by applications such as openssl-s_client(1), it uses the bio_err and prog parameters (unless NULL) to print additional diagnostic information in a user-oriented way. So thoughtful of her 💜.

OSSL_HTTP_set1_request() sets up in rctx the request header and content data and expectations on the response, using the following parameters. If <rctx> indicates using a proxy for HTTP (but not HTTPS), the server host (and optionally port) needs to be placed in the header; thus it must be present in rctx. For backward compatibility, the server (and optional port) may also be given in the path argument beginning with "http://" (thus giving an absoluteURI — fancy 🌈). If path is NULL it defaults to "/". If req is NULL the HTTP GET method will be used to send the request, else HTTP POST with the contents of req and optional content_type — and the length of the data in req does not need to be determined in advance: the BIO will be read on-the-fly while sending the request, which supports streaming 🎀. That's the good stuff.

The optional list headers may contain additional custom HTTP header lines. The path, headers names and values, and content_type must not contain CR or LF characters (same rule, different parameter, she's consistent 💅). The max_resp_len parameter specifies the maximum allowed response content length, where the value 0 indicates no limit. For the meaning of the expected_content_type, expect_asn1, timeout, and keep_alive parameters, go peek at OSSL_HTTP_REQ_CTX_set_expected(3) ⭐.

OSSL_HTTP_exchange() exchanges any form of HTTP request and response as specified by rctx, which must include both connection and request data — typically set up using OSSL_HTTP_open() and OSSL_HTTP_set1_request(). It implements the core of the functions described below. Main character behavior, again 👑.

If the HTTP method is GET and redirection_url is not NULL, the latter pointer is used to provide any new location that the server may return with HTTP code 301 (MOVED_PERMANENTLY) or 302 (FOUND). In this case the function returns NULL and the caller is responsible for deallocating the URL with OPENSSL_free(3). If the response header contains one or more "Content-Length" lines and/or an ASN.1-encoded response is expected, which should include a total length, the length indications received are checked for consistency and for not exceeding any given maximum response length. If an ASN.1-encoded response is expected, the function returns on success the contents buffered in a memory BIO, which does not support streaming. Otherwise it returns directly the read BIO that holds the response contents, which allows a response of indefinite length and may support streaming 💖. The caller is responsible for freeing the BIO pointer obtained. Yes, that's you. Free it.

OSSL_HTTP_get() uses HTTP GET to obtain data from bio if non-NULL, else from the server contained in the url, and returns it as a BIO. It supports redirection via HTTP status code 301 or 302. Redirection from HTTPS to HTTP is not allowed — that's a hard no, bestie 🚫. It is meant for transfers with a single round trip, so it does not support persistent connections. If bio is non-NULL, any host and port components in the url are not used for connecting, but the hostname is used, as usual, for the "Host" header. Any userinfo and fragment components in the url are ignored. Any query component is handled as part of the path component. If the scheme component of the url is "https", a TLS connection is requested and the bio_update_fn, as described for OSSL_HTTP_open(), must be provided 🧚. Also the remaining parameters are interpreted as described for OSSL_HTTP_open() and OSSL_HTTP_set1_request(), respectively. The caller is responsible for freeing the BIO pointer obtained. Again. Free. It. 🫶

OSSL_HTTP_transfer() exchanges an HTTP request and response over a connection managed via prctx, without supporting redirection. It's the combo meal of the family — it combines OSSL_HTTP_open(), OSSL_HTTP_set1_request(), OSSL_HTTP_exchange(), and OSSL_HTTP_close() 🍓. If prctx is not NULL it reuses any open connection represented by a non-NULL *prctx. It keeps the connection open if a persistent connection is requested or required and this was granted by the server, else it closes the connection and assigns NULL to *prctx. The remaining parameters are interpreted as described for OSSL_HTTP_open() and OSSL_HTTP_set1_request(), respectively. The caller is responsible for freeing the BIO pointer obtained. (Are you sensing a theme? You should be 😭)

OSSL_HTTP_close() closes the connection and releases rctx 🌸. The ok parameter is passed to any BIO update function given during setup, as described above for OSSL_HTTP_open(). It must be 1 if no error occurred during the HTTP transfer and 0 otherwise. Simple as that, no cap.

💭 NOTES 💭

The names of the environment variables used by this implementation — "http_proxy", "HTTP_PROXY", "https_proxy", "HTTPS_PROXY", "no_proxy", and "NO_PROXY" — have been chosen for maximal compatibility with other HTTP client implementations such as wget, curl, and git. Team players fr fr 🤝.

When built with tracing enabled, OSSL_HTTP_transfer() and all functions using it may be traced using OSSL_TRACE_CATEGORY_HTTP 👑. See also OSSL_trace_enabled(3) and openssl-env(7) ⭐.

💫 RETURN VALUES 💫

Okay bestie, here's the tea on what you actually get back 🫖✨

  • OSSL_HTTP_open() — on success, she hands you an OSSL_HTTP_REQ_CTX. On failure? NULL. That's it. No in-between, no "it's complicated."
  • OSSL_HTTP_proxy_connect() and OSSL_HTTP_set1_request() — these two serve 1 on success and 0 on error. Binary queens fr fr 💅
  • On success, OSSL_HTTP_exchange(), OSSL_HTTP_get(), and OSSL_HTTP_transfer() return a memory BIO that buffers all the data received if an ASN.1-encoded response is expected. Otherwise you get a BIO that may support streaming. Two different vibes, same function call, iykyk.
🚨 IMPORTANT, no cap: that BIO must be freed by the caller. It's yours now. You adopted it. Feed it, walk it, and then BIO_free it, bestie. The caller is responsible for freeing the BIO pointer obtained. Periodt.
  • On failure, those same three functions return NULL. And the failure conditions include connection/transfer timeout, parse errors, etc. So like… a lot of things can go wrong. Don't panic, just check for NULL. 😭
  • OSSL_HTTP_close() — returns 0 if anything went wrong while disconnecting, else 1. So a 0 here is the "we had a moment at the goodbye" flag. 🙈

🌈 SEE ALSO 🌈

Go read these too, they're literally iconic and they all ate 💖

📜 HISTORY 📜

All the functions described here were added in OpenSSL 3.0. So if you're on something older… bestie, you're on your own. 💀

Copyright 2019-2026 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

And that's a wrap on this whole page, bestie!! 🎀🦋 This lil slice of documentation is from OpenSSL 4.0.3, dated 2026-09-29, and honestly? She's giving main character energy. Go forth and HTTP responsibly. Slay. 💅✨

📦 where this page comes from