Expect: 100-continue in Modern Proxies

We’ve all been there, uploading a large file, only to have it fail halfway through. Say, uploading a 4K video file of about 20 GB storage, only to realize the website can not handle it. Frustrating, right?

In modern client devices like browsers, we can use a mechanism that asks the website, “Hey, check what I’m sending first. It is a large package. Should I proceed?” or I am about to send a request with this particular Content-Type. Do you support it?

Such mechanisms save clients time and bandwidth, avoid errors, and give a go-ahead before wasting resources. That’s the exact purpose of the 100-continue HTTP status response.

100-Continue

Like the other status codes within the 1xx series, 100-Continue is informational. Informational status codes don’t signal success or failure but instead act as forewarnings to the server.

The 100-continue status code offers several benefits for both clients and servers in situations involving large requests, particularly file uploads:

Client benefits:

• Reduced Bandwidth waste: The client avoids sending the entire request body if the server isn’t prepared to handle it, saving precious data and upload time.
• Early error detection: The server can quickly identify potential issues within the request (e.g., invalid format, file size exceeding limit) before the client invests significant time and bandwidth in uploading the entire file.
• Improved user experience: Faster upload times and fewer errors lead to a smoother and more pleasant user experience.

Server benefits:

• Resource management: The server can efficiently allocate resources(storage, processing power) based on the requirements of the incoming request, preventing overload and ensuring optimal performance for all users.
• Reduced error handling: Identifying problematic requests prevents unnecessary error handling and processing, improving overall efficiency.
• Enhanced security: The 100 continue status code can implement security checks, such as verifying file size or Content-Type, before accepting large uploads, potentially mitigating security risks.

100-continue in SKUDONET ADC.

In SKUDONET ADC, the Expect: 100-Continue response code configurations give you more control over how websites handle your requests. There’s no one-size-fits-all response. You get to choose how the server responds to the client, and we so far have four Modes of this status code. These include;

1. Pass
2. Ignore
3. Silent Pass
4. Not Allow.

Important Notice!

• The Expect: 100-Continue configurations in SKUDONET ADC are supported and compatible with the HTTP/1.1 requests.
• Additionally, only Use this rule primarily with the LSLB Farm profile having the HTTP listener for each of these four modes.

Pass

When a client sends a request with the Expect: 100-continue header, the load balancer simply forwards the entire request (including the header) to the backend server without any modification. This mode is suitable when you want the backend server to have full control over handling the Expect: 100-continue header.

Here’s how the communication works in Pass mode:

A Client sends a request with the Expect: 100-Continue header. The load balancer receives the request with the header intact. It then forwards the entire request to the backend server.

The backend then determines if it can handle the data and responds accordingly:

• If ready: The server sends the Code 100.
• If not, the server sends any other valid status code.

The load balancer receives the response from the backend server and forwards the response (including the status code) to the client.

If the status Code is 100, the client sends the request data in chunks. If the response is any other code, it handles the error as appropriate (e.g., display an error message).

The load balancer then receives the client’s request data and forwards the entire request to the backend server.

If the transaction is successful, the backend server may respond to the client with an HTTP code (e.g., 201-File saved to the database) via the load balancer. If the response is any other code, it handles the error as appropriate (e.g., display an error message).

Ignore

When the load balancer receives the Expect: 100-Continue header in the client request, it immediately ignores it, not sharing this information with the server or the client, meaning it does not reach the backend server.

However, the client immediately responds to the server. It then sends the request data in the request body. The load balancer then forwards this data to the backend server. Note that this data does contain the Expect: 100-Continue header.

After uploading, the backend server responds with a status code and a message informing the client if the action was a success or a failure. This Status code could be 201(New resource created successfully), 413(Request body exceeds allowed size), 415(Unsupported Media Type), 507(Server has insufficient storage for the request), etc.

Silent Pass

In this mode, the load balancer does not forward the Expect: 100-Continue header to the backend server, but it directly responds to the client, telling it to proceed with the request.

Based on the image below, here is a brief illustration of how this works.

A client initiates a request to the load balancer, including the Expect: 100-Continue header, notifying it that it’ll likely send a file.

Then, the load balancer responds to the client with the status code: 100 without inquiring from the backend servers. This is to inform the client to proceed.

After, the client sends the data of the request body in chunks to the load balancer. The load balancer then forwards this data to the backend server.

After uploading, the backend server may respond with a status code and a message informing the client if the action was a success or a failure.

Not Allow

When the load balancer detects the Expect: 100-Continue header in the client request, it immediately responds with a 417 Expectation Failed status code. This code explicitly tells the client that the Expect: 100-Continue can not be used. Therefore, the client should make another request without this header.

Here is an illustration.

The client sends a request with the Expect: 100-continue header and the necessary information for the backend server to process.

Upon receiving a request with the Expect: 100-continue header, the load balancer immediately closes the connection or refuses to forward the request. Instead, it responds with a 417 Expectation Failed status code to the client device, indicating that the backend server(s) cannot fulfill the client’s expectations.

How to configure 100-continue in SKUDONET ADC.

Before you start, ensure you have a Layer 7 Farm configured to receive inbound traffic for your web application. If not, check out this article on creating a Layer 4 and 7 Farm.
To enable the 100-Continue status code in your ADC:

1. 1. Navigate to LSLB > Farms.

1. 1. Put over the HTTP farm for your web application and click the Pencil icon to edit it.

1. 1. Within the farm’s Global settings, click the Advanced tab.

1. 1. Scroll down to the Advanced Settings section. You will see the 100-continue Mode setting, ensure that HTTPS profile is activated.
   2. Choose the desired mode from the four options listed.

1. Scroll down and click Apply to save your changes.
2. Restart the farm for the new changes to take effect.