100 Continue

100 Continue is a status-code you might not deal with very often. Generally, as a web developer, the 100 Continue status is sent under the hood by your webserver.

So what’s it for? The best example comes from RFC 7231. Say, you’re sending a large object to the server using a PUT request, you may include a Expect header like this:

PUT /media/file.mp4  HTTP/1.1
Host: api.example.org
Content-Length: 1073741824
Expect: 100-continue

This tells the server that it should respond with a 100 Continue status code if the server is going to be able to accept the request:

HTTP/1.1 100 Continue

When the client receives this, it tells the client the server will accept the request, and it may start sending the request body.

The big benefit here is that if there’s a problem with the request, a server can immediately respond with an error before the client starts sending the request body.

A simple use-case is that a server might first require authentication using 401 Unauthorized, or it might know in advance that the Content-Type that the client wants to send to the server is not something the server will want to accept.

Unfortunately, it’s not always possible to take advantage of this feature. PHP for example has no event you can hook into to tell the client early that it should stop sending the request. PHP scripts only start after the full request has been received, which is too late.

An example of a language that does have support is Node.js. Node.js has a checkContinue event on its http.Server class that can be listened to, to potentially send an early error code (source). If a user doesn’t implement this event Node.js will send the 100 Continue status by default.

My personal experience with 100 Continue is mostly confusion and frustration. For a while I didn’t really understand what it meant, and Nginx in particular didn’t have support for it for many years (it does now). This broke a number of obscure clients I had to deal with for a project I was working on.

HTTP series

This article is part of an ongoing series about the HTTP protocol.

If you want to follow along as I write them, you can Subscribe to my Atom feed or Mailing list.

Archive

Web mentions