100 Continue

RFC 9110 describes the handshake in sections 10.1.1 and 15.2.1. The client sends its headers with Expect: 100-continue and pauses. The server either answers 100 Continue, and the client streams the body, or it goes straight to a final status such as 401, 413 or 417, and the upload never starts.

Clients are not required to wait forever. curl waits one second by default (the --expect100-timeout option) and then sends the body anyway, which is why uploads through a server or proxy that ignores the expectation start with a short, unexplained pause. Browsers never take part: the Fetch standard lists Expect as a forbidden request header, so you only meet 100 Continue with command-line tools, storage SDKs and server-to-server clients.

• You rarely send it by hand: Node answers 100 Continue automatically unless you listen for the checkContinue event, and Go sends it the first time your handler reads r.Body.
• Take control when you want to reject uploads before they begin: check Content-Length, authentication or quota first, and only then let the body through.

If you run the server

• Uploads stall for about one second before starting: the client is waiting for a 100 that a proxy or server never sends.
• An old proxy or appliance answers 417 Expectation Failed because it does not understand the Expect header.

If you run the server

• Disable the expectation on the client when you control it: curl -H "Expect:" sends the body immediately.
• Make sure every hop forwards or answers the expectation; if one cannot, strip Expect at the edge rather than letting clients time out.

Next.js route handlers and FastAPI have no hook for this: the underlying Node or Uvicorn server replies 100 Continue for you.

import http from 'node:http';
import app from './app.js'; // your Express app

const server = http.createServer(app);

// Without this listener Node answers 100 Continue by itself.
server.on('checkContinue', (req, res) => {
  const size = Number(req.headers['content-length'] ?? 0);
  if (size > 50 * 1024 * 1024) {
    res.writeHead(413).end(); // refused before any byte is uploaded
    return;
  }
  res.writeContinue(); // 100 Continue
  app(req, res);
});

server.listen(3000);

mux.HandleFunc("PUT /uploads/{name}", func(w http.ResponseWriter, r *http.Request) {
	// Reject before reading: the client never uploads the body.
	if r.ContentLength > 50<<20 {
		http.Error(w, "file too large", http.StatusRequestEntityTooLarge)
		return
	}
	f, err := os.Create(filepath.Join("uploads", filepath.Base(r.PathValue("name"))))
	if err != nil {
		http.Error(w, "cannot store file", http.StatusInternalServerError)
		return
	}
	defer f.Close()
	n, _ := io.Copy(f, r.Body) // first Read sends "100 Continue" (StatusContinue)
	fmt.Fprintf(w, "stored %d bytes\n", n)
})

# See the handshake: curl prints "HTTP/1.1 100 Continue" before the final status
curl -v -T big-file.bin https://example.com/uploads/big-file.bin

# Skip the handshake and send the body right away
curl -H "Expect:" -T big-file.bin https://example.com/uploads/big-file.bin

100 vs 417

417 Expectation Failed is the refusal: the server cannot meet the Expect header, so the client should retry without it.

100 vs 103

103 Early Hints is also interim, but it carries Link headers about the response; 100 is only about whether to send the request body.

Do browsers use 100 Continue?

No. The Fetch standard forbids pages from setting the Expect header, and browsers do not add it themselves. You see 100 Continue with curl, storage SDKs such as the AWS SDKs uploading to S3, and other non-browser clients.

Why does curl pause for a second before uploading?

For larger uploads curl sends Expect: 100-continue and waits up to one second for the 100 response. If nothing arrives it sends the body anyway. Pass -H "Expect:" to skip the wait, or --expect100-timeout to change it.

Is 100 Continue an error?

No. It is an interim 1xx response that is always followed by a final status on the same request. The final one, 201 or 413 for example, is what tells you whether the upload worked.