1xx Informational Codes

Introduction

HTTP status codes are grouped into categories, and the 1xx range is the informational category. These status codes indicate that the server has received the client's request and that processing is continuing. Unlike common success or error responses, 1xx responses are not final results. They are temporary signals sent before the final response. A client may receive a 1xx response during a large upload, protocol upgrade, long-running operation, or performance optimization flow, and then later receive the actual final status code such as 200 OK, 201 Created, 400 Bad Request, or 500 Internal Server Error.

Most everyday REST API testing does not involve 1xx responses frequently. API testers usually work with 2xx success codes, 4xx client errors, and 5xx server errors. However, 1xx responses are still important because they explain advanced HTTP behavior. They appear in large file uploads, WebSocket upgrades, WebDAV processing, early resource loading, and some gateway or infrastructure-level scenarios. They are also useful in interviews because they show that you understand HTTP beyond only the most common status codes.

Understanding 1xx status codes helps testers avoid wrong assumptions. A 100 Continue response does not mean the upload completed. A 101 Switching Protocols response does not mean a normal REST response body is coming next. A 102 Processing response is not final success. A 103 Early Hints response does not replace the final HTML or API response. These codes tell the client that something is happening before the final response is available.

In simple terms, 1xx informational codes indicate that the server has received the request and processing is continuing. They are interim responses, not final outcomes.

What Are 1xx Informational Codes?

The 1xx status code range includes HTTP responses from 100 through 199. These responses are informational, temporary, and normally followed by another final status code. They are part of the HTTP protocol's way of managing communication between the client and server before the complete request or response is finished.

A 1xx response communicates one of several ideas. The server may be telling the client to continue sending the request body. It may be agreeing to switch protocols. It may be telling the client that a long-running request is still being processed. It may be sending early headers so the client can start preparing resources before the final response arrives.

The key point is that a 1xx response is not the final answer. A client should not treat it as final success or failure. It should continue the HTTP exchange according to the meaning of the specific informational code. The final response will come later and will usually be a 2xx, 3xx, 4xx, or 5xx status code.

Common 1xx status codes include 100 Continue, 101 Switching Protocols, 102 Processing, and 103 Early Hints. These are not used equally. 100 and 101 are more familiar in general HTTP discussions, while 102 is associated with WebDAV and 103 is connected to web performance optimization.

Range and Summary of Common 1xx Codes

The range for informational status codes is:

100 - 199

The most commonly discussed codes in this range are summarized below:

The common characteristic across all these responses is that they are intermediate. They help manage the communication process, but they do not communicate the final business result. A client must wait for the final response to know whether the request really succeeded or failed.

100 Continue

100 Continue tells the client that the server has received the request headers and that the client may continue sending the request body. This is useful when the request body is large, such as a file upload, video upload, backup archive, or large data import. Instead of sending a huge body immediately, the client can first ask whether the server is willing to accept it.

The flow usually starts with the client sending request headers that include Expect: 100-continue. The server checks the headers. It may validate authorization, content length, content type, route, and basic request acceptability. If the server is willing to receive the body, it responds with 100 Continue. Then the client sends the body. After processing the complete request, the server sends a final response such as 201 Created or 400 Bad Request.

Client
  |
  | Request headers with Expect: 100-continue
  v
Server
  |
  | HTTP/1.1 100 Continue
  v
Client sends request body
  |
  v
Server processes request
  |
  v
HTTP/1.1 201 Created

A request may look like this:

POST /upload HTTP/1.1
Host: api.example.com
Expect: 100-continue
Content-Length: 2147483648

If the headers are acceptable, the server responds:

HTTP/1.1 100 Continue

The client then uploads the file. Later, the server may return:

HTTP/1.1 201 Created

The benefit is efficiency. If the server would reject the request because authentication is missing or the content type is not allowed, the client can avoid sending a massive body unnecessarily. This saves bandwidth, reduces wasted server work, and improves performance for large uploads.

Testing 100 Continue

Testing 100 Continue requires understanding whether the API or infrastructure actually supports the expectation flow. Not every API client exposes this behavior clearly, and not every server uses it. When it is part of the design, testers should verify that the server responds with 100 Continue only when the request headers are acceptable and that the final response still reflects the real result of the complete upload.

For a large upload API, testers should check valid headers, invalid authentication, unsupported media type, content length limits, and successful upload. If authentication is missing, the server should reject the request early rather than ask the client to send a large body. If the server accepts the headers, it should handle the body and return the appropriate final status code.

A common mistake is treating 100 Continue as success. It is not success. It only means the client may continue sending the body. The upload may still fail later because of virus scanning, storage failure, validation error, timeout, file size violation, or business rule failure. API test reports should distinguish interim responses from final responses.

101 Switching Protocols

101 Switching Protocols indicates that the server has accepted the client's request to switch from the current protocol to another protocol. It is commonly associated with WebSocket upgrades. A client begins with an HTTP request and asks the server to upgrade the connection. If the server accepts, it returns 101 Switching Protocols, and communication continues using the new protocol rather than ordinary HTTP request-response behavior.

A simplified WebSocket upgrade request may include headers like:

GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade

If the server accepts the upgrade, it responds:

HTTP/1.1 101 Switching Protocols

After this point, the connection no longer behaves like a normal REST API call. It becomes a WebSocket connection that can support real-time bidirectional communication. Chat applications, live notifications, trading dashboards, multiplayer systems, and collaboration tools may use this kind of communication.

HTTP Connection
  |
Upgrade Request
  |
101 Switching Protocols
  |
WebSocket Connection

For testers, 101 matters when validating real-time systems. A normal REST API tool may not be enough after the upgrade. The tester may need WebSocket-capable tools, browser developer tools, or specialized automation libraries to validate messages after the protocol switch.

Testing 101 Switching Protocols

Testing 101 Switching Protocols begins with the upgrade handshake. The client must send the correct upgrade headers, and the server must respond correctly when the upgrade is allowed. If headers are missing, authentication is invalid, or the endpoint does not support upgrade, the server should reject the request with a documented final status code rather than switching protocols.

After the protocol switch, testing must continue at the new protocol layer. In a WebSocket chat application, testers should validate connection establishment, message send, message receive, authentication, authorization, reconnect behavior, heartbeat or ping-pong behavior, idle timeout, message ordering, and error handling. The 101 response only confirms that the connection changed protocols; it does not prove the business messaging works.

Security testing is also important. WebSocket endpoints should not allow unauthorized upgrades. They should validate tokens, origins, and permissions according to the application design. A server that upgrades any request without checks can expose real-time channels to unauthorized users.

102 Processing

102 Processing means the server has received the request and is still processing it, but no final response is available yet. It was primarily defined for WebDAV, which extends HTTP for distributed authoring and document management. In everyday REST API testing, 102 is uncommon, but the concept is still useful for understanding long-running operations.

Some requests take time. A server may be processing many files, updating a document repository, validating a large batch, or performing complex server-side work. Instead of leaving the client unsure whether the request is stalled, the server can send 102 Processing to indicate that work is continuing.

Client
  |
Large request
  v
Server
  |
102 Processing
  |
Still working
  |
200 OK

This response does not mean the operation succeeded. It only means the server has not finished. The final response may still be success or failure. For modern REST APIs, long-running work is often handled with 202 Accepted and a job-status endpoint instead of 102 Processing. Still, understanding 102 helps testers recognize that some HTTP responses are interim signals.

Testing 102 Processing

If an application uses 102 Processing, testers should verify that it appears only during operations that genuinely need processing time and that the final response is eventually returned. The client should not hang forever. Timeouts should be reasonable, and the server should avoid sending endless processing signals without completing or failing the operation.

For long-running operations, testers should validate both timing and final outcome. Does the client remain connected correctly? Does the server send the final status? Does the operation complete correctly in the database or document store? What happens if processing fails halfway? Does the client receive a controlled error?

In many modern APIs, testers are more likely to see 202 Accepted than 102 Processing. The difference is important. 102 is interim while the original request continues. 202 is a final response for the initial request indicating that processing has been accepted and will continue asynchronously. Mixing these concepts can create incorrect test expectations.

103 Early Hints

103 Early Hints allows the server to send preliminary response headers before the final response is ready. Its main purpose is web performance optimization. The server may know that the final page will need certain CSS files, JavaScript files, fonts, or other resources. Instead of waiting until the full HTML is generated, the server can send early hints so the browser starts loading critical resources sooner.

An early hints response may look like this:

HTTP/1.1 103 Early Hints
Link: </styles.css>; rel=preload

The browser can begin downloading styles.css while the server continues generating the final page. Later, the server sends the final response:

HTTP/1.1 200 OK
Content-Type: text/html

This can reduce perceived latency and improve page-loading performance. It is more relevant to browser-facing web performance than typical JSON API testing, but it still belongs to HTTP status-code knowledge. API testers working with web performance, frontend delivery, or gateway behavior may encounter it.

Testing 103 Early Hints

Testing 103 Early Hints requires tools that can observe interim responses and headers. Some high-level clients hide 1xx responses, so browser developer tools, network captures, server logs, or specialized HTTP clients may be needed. The tester should verify that the early hint headers are correct and that the final response remains correct.

The main validation points are whether the hinted resources are useful, whether the links are valid, whether they use the right preload relationship, and whether they improve performance without causing unnecessary downloads. Sending early hints for unused resources can waste bandwidth and hurt performance rather than improve it.

Testers should also ensure that early hints do not expose sensitive information. Preliminary headers should not reveal private user-specific resources or internal paths in ways that create security or privacy concerns. As with all performance optimizations, correctness and security still matter.

Characteristics of 1xx Responses

1xx responses have several consistent characteristics. They are temporary. They are not final. They are mainly used for protocol control, communication coordination, and optimization. They are less common in everyday REST API development than 2xx, 4xx, and 5xx responses. They are normally followed by another response that communicates the final outcome.

Because they are interim responses, clients and testing tools may handle them differently. Some tools show them clearly. Some tools hide them and show only the final response. Some libraries process them internally. This can make testing 1xx behavior more difficult than validating ordinary status codes.

For API testers, the main rule is to avoid treating a 1xx response as final success. Always check the final response. If a file upload receives 100 Continue and later fails with 413 Payload Too Large, the operation failed. If a WebSocket handshake returns 101, the protocol switched, but application-level message validation still remains. If a page receives 103 Early Hints, the final page response still matters.

1xx Responses in REST APIs

In typical REST APIs, 1xx responses are rare. Most API testers spend their time validating 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests, and 500 Internal Server Error. These final responses directly describe the result of API operations.

However, REST APIs may still encounter 1xx behavior in specialized cases. Large upload endpoints may use 100 Continue. Real-time APIs may use 101 Switching Protocols to upgrade to WebSockets. Document-management systems may encounter 102 Processing. Browser-facing systems may use 103 Early Hints to improve loading performance.

This means testers should not ignore 1xx codes completely. They should know what they mean, recognize when they are expected, and understand which tool can observe them. For most API automation suites, final response validation remains the main focus, but advanced flows may require 1xx-aware testing.

API Testing Considerations

Testing 1xx responses starts with confirming whether the system is expected to use them. If the API specification does not mention 1xx behavior and the application does not involve uploads, protocol upgrades, WebDAV, or early hints, then ordinary API tests may not need dedicated 1xx assertions. If the design does include these features, the tests should validate them deliberately.

For 100 Continue, verify that the server responds appropriately when request headers are acceptable and that large uploads proceed only when expected. Also test rejection cases where the server should avoid receiving a large body, such as missing authorization or unsupported media type.

For 101 Switching Protocols, verify the upgrade handshake and then validate communication using the upgraded protocol. A successful switch is only the beginning. The real business behavior happens after the switch.

For 102 Processing, verify that long-running operations do not appear stalled and that a final response eventually arrives. For 103 Early Hints, verify that early headers are correct, useful, secure, and followed by the correct final response.

Test tooling matters. If your tool hides interim responses, you may need network traces, logs, browser tools, or lower-level HTTP clients. The goal is to prove the communication behavior, not merely assume it from the final response.

Real-World Examples

A cloud storage application uploading a 5 GB backup file is a practical 100 Continue example. The client first sends headers with Expect: 100-continue. The server verifies whether the request is acceptable. If it is, the server sends 100 Continue, and the client uploads the file. The final response may be 201 Created if the upload succeeds.

A chat application is a practical 101 Switching Protocols example. The client starts with an HTTP request asking to upgrade to WebSocket. The server returns 101, and then messages can flow in both directions over the WebSocket connection. Testing must include the handshake and the real-time message behavior.

A document management system processing a large batch of files may use 102 Processing to indicate that work is still happening. The client knows the server has not stopped responding, but it still must wait for a final response.

An e-commerce website using 103 Early Hints may instruct the browser to preload CSS and fonts before the full HTML response is generated. This improves page load experience when implemented correctly. The final response must still return the correct page.

Common Misconceptions

A common misconception is that 1xx responses indicate success. They do not. They indicate that processing is continuing or that the communication flow is moving to another step. The final outcome is communicated by a later response.

Another misconception is that 100 Continue means the upload is complete. It only means the client may begin or continue sending the request body. The server can still reject the final uploaded content later.

A third misconception is that most REST APIs use 1xx responses frequently. In practice, most REST API testing focuses on final response codes such as 2xx, 4xx, and 5xx. 1xx responses appear in specialized scenarios, not in every API call.

Another misconception is that API automation tools always expose 1xx responses. Some clients process interim responses internally and show only the final response. Testers should understand tool behavior before concluding that a 1xx response was or was not sent.

Best Practices

Use 1xx responses only when they fit the communication need. Do not add them to ordinary API flows just for complexity. They are useful for large uploads, protocol upgrades, long-running processing signals, and performance hints. Most normal REST operations do not need them.

Always send a final response after an informational response. A 1xx response should not leave the client waiting forever. The final response should clearly indicate success, redirection, client error, or server error.

Document expected 1xx behavior. If an upload API uses 100 Continue, explain it. If a WebSocket endpoint returns 101, document the upgrade requirements. If early hints are used for performance, document the expected link headers and final response behavior.

Use the right testing tools. Some 1xx behavior requires lower-level network visibility. Browser developer tools, curl, server logs, proxy tools, and specialized WebSocket clients may be more useful than basic API clients for these cases.

Keep security in mind. Protocol upgrades should validate authentication and origin rules. Early hints should not expose sensitive resource paths. Large upload flows should validate authorization and size limits before accepting big payloads.

How 1xx Responses Appear in Tools and Logs

One reason 1xx status codes confuse beginners is that they do not always appear clearly in every tool. A browser, API client, automation library, reverse proxy, or server log may show only the final response. For example, if a client sends a large upload request and the server sends 100 Continue before accepting the body, the final API testing report may show only 201 Created or 400 Bad Request. The interim response happened, but the tool may have handled it internally.

This makes observation an important part of testing. If the project requirement says that the server must support 100 Continue, a tester should not rely only on the final response shown by a simple API client. The tester may need to use curl with verbose output, browser network tools, server-side request logs, proxy logs, gateway traces, or packet capture tools. The exact tool depends on the application architecture, but the principle is the same: the test evidence should prove that the interim behavior occurred, not merely prove that the final response was successful.

In distributed systems, 1xx responses may also be affected by infrastructure. A load balancer, API gateway, CDN, or reverse proxy may pass through, suppress, rewrite, or generate certain headers. This is especially important for 103 Early Hints, because a CDN or edge server may be involved in sending early link headers before the origin server finishes generating the final page. If early hints are part of a performance strategy, testers should verify behavior at the user-facing edge, not only at the origin service.

Logs can also be misleading if they are not designed to record interim responses. Many application logs record the final status code only. Access logs may show 200, 201, or 500 while omitting 100 or 103. This is not necessarily a defect; it may simply be how the logging layer summarizes requests. When troubleshooting, testers should ask which layer is responsible for the 1xx response and which log source can actually confirm it.

1xx Responses vs Final HTTP Status Codes

The most important distinction is that 1xx responses are interim, while 2xx, 3xx, 4xx, and 5xx responses are final for the request. A final status code tells the client what happened to the operation. A 1xx response tells the client that something is happening before the final result is ready. This distinction matters because test cases should assert the correct kind of result at the correct point in the communication flow.

For example, 100 Continue should not be treated like 200 OK. 100 Continue says the request may continue. 200 OK says the request succeeded. Similarly, 101 Switching Protocols is not the same as a completed business operation. It says that the protocol switch is accepted. After that switch, the tester must still validate whether the real-time messages, subscriptions, notifications, or stream events work correctly.

This also affects error handling. A request can receive an informational response and still fail later. A large file upload may receive 100 Continue, send the body, and then fail because the body exceeds a configured size limit. A WebSocket handshake may receive 101 Switching Protocols, but the connection may close immediately because of an authorization or message-format problem. A page may receive 103 Early Hints, but the final HTML response may still be 500 Internal Server Error. In all of these cases, the interim response does not override the final result.

From an automation design perspective, this means the assertion strategy should be layered. First, verify the interim status only if it is part of the contract. Second, verify the final HTTP response. Third, verify the business outcome. For most APIs, the second and third checks are enough. For advanced flows such as uploads, WebSockets, and early hints, the first check becomes useful because it validates the communication behavior expected by the architecture.

Designing Automation Around 1xx Status Codes

Automated tests for 1xx responses should be selective. It is usually unnecessary to add 1xx checks to every REST API test. Doing so would make the suite more complex without adding much value. Instead, identify the few endpoints where interim responses are actually part of the design. These may include upload endpoints, streaming endpoints, WebSocket upgrade endpoints, WebDAV operations, or browser-facing endpoints optimized with early hints.

For upload testing, automation should cover both accepted and rejected paths. The accepted path verifies that the server allows the client to send a request body when headers are valid. The rejected path verifies that the server can reject the request early when headers are invalid, authorization is missing, the content type is unsupported, or the file size is clearly outside policy. This saves server resources and creates better client behavior.

For protocol switching, automation should not stop at the handshake. A test that only checks 101 Switching Protocols proves that the server accepted the upgrade, but it does not prove that the real application behavior works. A stronger test opens the upgraded connection, sends a valid message, receives an expected response, checks authorization behavior, and closes the connection cleanly. This turns a transport-level check into a meaningful application-level test.

For early hints, automation should focus on correctness and usefulness. The hinted resources should exist, be cacheable when appropriate, use correct paths, and support the intended performance improvement. The test should also verify that the final response remains correct. A performance optimization that breaks correctness is not a successful optimization.

When choosing tools, testers should confirm whether the chosen client exposes interim responses. REST Assured, browser automation tools, command-line clients, and low-level HTTP libraries may differ in what they show directly. If the tool does not expose the interim response but the feature must be validated, combine API automation with logs, proxy inspection, or targeted command-line checks. Practical automation is not about forcing every tool to do everything; it is about collecting reliable evidence with the right level of effort.

Troubleshooting 1xx Issues in Real Projects

When a 1xx-related defect appears, start by identifying where the response is generated. Is it coming from the application server, a framework, an API gateway, a web server, a CDN, or a reverse proxy? Without this clarity, teams may debug the wrong layer. For example, a backend developer may search application code for 103 Early Hints even though the CDN is actually generating the early hint headers.

Next, compare expected behavior with actual behavior. If 100 Continue is missing, check whether the client sent the Expect: 100-continue header. If 101 Switching Protocols fails, check upgrade headers, authentication, origin restrictions, and supported protocols. If 102 Processing appears but no final response arrives, inspect timeout settings and backend job completion. If 103 Early Hints is sent with incorrect links, review routing, asset paths, build output, and cache rules.

It is also useful to test through the same path that real users use. A local service call may behave differently from a call routed through a gateway, CDN, WAF, and load balancer. Since 1xx responses are often connected to protocol behavior and infrastructure, environment differences matter. A feature may work in local testing but disappear in staging because a proxy does not pass interim responses as expected.

Finally, keep the defect report precise. Instead of writing "API status code is wrong," describe the exact communication issue: expected 100 Continue was not observed before sending a large body; WebSocket upgrade returned 400 instead of 101; early hints include a missing stylesheet path; processing response is sent repeatedly but final response never arrives. Specific reports help developers find the correct layer quickly.

Interview-Ready Explanation

1xx informational HTTP status codes are temporary responses indicating that the server has received the client's request and is continuing to process it. They are not final responses and are usually followed by another status code that communicates the final outcome.

Common examples include 100 Continue, which tells the client that request headers are accepted and the client may send the request body; 101 Switching Protocols, which indicates the server agrees to switch protocols such as upgrading HTTP to WebSocket; 102 Processing, which indicates that a long-running request is still being processed; and 103 Early Hints, which sends preliminary headers so clients can preload resources before the final response is ready.

In most REST API testing, 1xx responses are uncommon because testers usually validate final responses such as 2xx, 4xx, and 5xx. However, understanding 1xx codes is useful for large uploads, WebSocket upgrades, long-running operations, browser performance optimization, and advanced HTTP interview questions.

The key point is that 1xx means "continue, wait, switch, or prepare." It does not mean the request has finally succeeded.

Key Takeaway

1xx informational status codes are interim HTTP responses. They help coordinate communication between client and server before the final response is available. They are useful for cases such as large upload negotiation, protocol switching, long-running processing, and early resource loading.

For API testers, the practical rule is simple: do not treat a 1xx response as final success. Validate the interim behavior only when the system is expected to use it, and always verify the final response and business outcome. If the application uses uploads, WebSockets, WebDAV, or early hints, then 1xx responses become part of the test scope.

The simplest summary is this: 1xx responses are temporary HTTP signals. They tell the client that the request is received, processing is continuing, a protocol switch is accepted, or early hints are available, but the final result still comes later.