Understanding “Mark bundle as not supporting multiuse” in curl HTTP/1.1 Connection Behavior


2 views

When examining verbose curl output (curl -v), the message * Mark bundle as not supporting multiuse appears during HTTP/1.1 connections. This indicates the server explicitly declined connection reuse through the Connection: close header.

The message originates from curl's internal handling of HTTP/1.1 connections. Key points:

/* Simplified from curl/lib/http.c */
if(conn->bits.close) {
  infof(data, "Mark bundle as not supporting multiuse");
  bundle->multiuse = BUNDLE_NO_MULTIUSE;
}

Common triggers:

  • Server sends Connection: close
  • HTTP/1.0 responses (which default to close)
  • Specific proxy configurations

In containerized environments, you might see this when:

# Example showing the behavior in a container
$ docker run -p 8080:80 nginx
$ curl -v http://localhost:8080

> GET / HTTP/1.1
< HTTP/1.1 200 OK
< Connection: close
* Mark bundle as not supporting multiuse

This affects performance in HTTP clients that implement connection pooling:

// Python requests example showing connection close
import requests
r = requests.get('http://your-container')
print(r.headers.get('Connection'))  # May show 'close'

For common web servers:

Nginx:

http {
    keepalive_requests 100;
    keepalive_timeout 75s;
}

Apache:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

To investigate further:

# Check raw headers
curl -s -D - http://endpoint -o /dev/null

# Test with forced HTTP/1.1
curl --http1.1 -v http://endpoint

When examining curl verbose output (-v flag), you might encounter this message during HTTP/1.1 requests:

* Mark bundle as not supporting multiuse

This indicates curl's internal handling of HTTP/1.1 connection reuse. Unlike HTTP/2 which multiplexes requests, HTTP/1.1 connections are typically single-use by default unless explicitly kept alive.

The message appears in libcurl's verbose output when:

  1. The server didn't include "Connection: keep-alive" header
  2. The HTTP response lacks Content-Length or Transfer-Encoding headers
  3. Connection reuse would be unsafe/undefined

Example triggering scenario (Docker container with simple HTTP server):

docker run -p 8080:80 nginx
curl -v http://localhost:8080/

When you see this message, curl will:

  • Close the TCP connection after this request
  • Not attempt to reuse the connection for subsequent requests
  • Establish new connections for each request

For performance-critical applications, you might want to ensure proper keep-alive support:

# Server-side configuration example (nginx)
http {
    keepalive_timeout 65;
    keepalive_requests 100;
}

To analyze connection reuse behavior:

curl -v --trace-ascii debug.txt http://your-endpoint/
# Check for these key markers:
# - Connection: keep-alive
# - Keep-Alive: timeout=5, max=100

With HTTP/2, you won't see this message because:

curl --http2 -v https://http2.website.example
# Multiplexing eliminates single-use connection limitations