The headers were fine; send the body. Used with Expect: 100-continue so a client does not upload a large body that would be rejected. 100 belongs to the 1xx informational class and is defined in RFC 9110.
Loading the workbench.
The headers were fine; send the body. Used with Expect: 100-continue so a client does not upload a large body that would be rejected. The code is registered with IANA and defined in RFC 9110.
Informational: the request was received and the process continues. Every code from 100 to 199 shares that general meaning, so a client that does not recognise 100 must treat it like 100.
You see 100 Continue when a client sends Expect: 100-continue before a large upload. The server reads the headers first and, if it is willing to accept the body, answers 100 so the client starts streaming. curl does this automatically for POST and PUT bodies above about one megabyte. It is an interim response: a final status such as 200, 201, or 413 always follows on the same request.
Clients normally need do nothing; HTTP libraries handle the handshake and wait a short time before sending anyway. If an old proxy stalls on Expect, remove the header (curl accepts -H 'Expect:'). Servers should answer 100 only after checking authentication, size limits, and Content-Type, and should send a final error such as 401 or 413 instead of 100 when they already know the upload will be refused.
HTTP/1.1 100 Continue100 is not cacheable by default: a browser or CDN stores it only when Cache-Control or Expires explicitly allows it.
To inspect a real one without sending it anywhere:
curl -i.Browse every code on the HTTP status codes page.
Elsewhere in 2http: Header decoder, Cookie decoder, Cache-Control decoder, CORS checker, User-agent parser, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.
curl sends Expect: 100-continue for large bodies and waits for the server to answer 100. If the server never replies, curl gives up waiting after a timeout and sends the body anyway, which looks like a pause.
Yes. HTTP/2 and HTTP/3 still support the Expect header and the interim 100 response, sent as a separate HEADERS frame before the final response on the same stream.
No. 100 is a informational response, not an error.
No. Caches store a 100 only when Cache-Control or Expires explicitly allows it.
You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
F12, or Cmd+Option+I on a Mac, and select the Network tab.Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.