Appendix B. HTTP Status Codes

All response status codes used and defined by WebDAV are listed here. Many of the HTTP/1.1 codes are used as is by WebDAV without attaching any additional meaning. For completeness, all HTTP/1.1 codes are described here, because all WebDAV clients must also be HTTP clients and can expect to see any of these codes from a server.

Each status code is listed with a brief gloss of its meaning or use and a reference to the specification in which it is first defined. Status codes are ordered numerically , since the first digit provides some guidance as to the kind of status being reported .

Current and in-progress WebDAV extensions do not define new numerical codes. It's difficult to define and use numerical codes without risk of collision with other HTTP extensions. Instead, DeltaV, ACL, and other WebDAV extensions use the most appropriate numerical error code and then in the body of the error response include an XML error code. Those XML codes are not covered here. Clients must still be able to get a general idea of the class of failure from the numerical code, even when most of the information is in the XML error code.

B.1 Informational Status Codes

Status codes from 100-199 are classified as "Informational." They are not successes, failures, or redirections.

B.1.1 100 Continue

The 100 Continue response indicates that the server is ready to receive the body of the request. This is only used if the client asked for confirmation before sending the body, by using the Expect: 100-continue header in the request, as explained in "Predicting Success for Lengthy Requests " in Chapter 3, HTTP Mechanics . Servers must handle this feature, but clients aren't required to. As an example, a client might use the Expect header together with the Content-Length header in a PUT request to confirm that the server is willing to handle a file of a given size. If the server cannot, it should send 417 Expectation Failed.

Defined in HTTP/1.1.

B.1.2 101 Switching Protocols

101 Switching Protocols indicates that the server will now begin communicating using a different protocol. This is only used when the Upgrade header is sent in the request and the server decides to switch.

Defined in HTTP/1.1.

B.1.3 102 Processing

102 Processing is used by a WebDAV server to indicate that it is working on a time-consuming request. For example, a depth infinity MOVE request to a large collection could take some time to complete. Clients may time out lengthy requests under the assumption that the request was ignored or dropped somehow. This status code allows the server to let the client know that it shouldn't time out the request, that the server is still working on the real response. Clients must support this response code, since the server can return it in any time-consuming operation. Servers are not required to use this response code.

Defined in WebDAV.

B.2 Success Status Codes

The status codes in the 200-299 range are all success responses of some kind or another. Not all successes are equal, however, and often clients need to know exactly how a request succeeded.

B.2.1 200 OK

200 OK is the basic success code for responses that are accompanied with a body. Whenever a basic GET request is successful, this code is used to return the resource's body.

Defined in HTTP/1.1.

B.2.2 201 Created

201 Created is used to indicate that the server created a new resource as a result of the request. PUT, MKCOL, LOCK, and COPY all return 201 Created when a new resource is created. This status response does not typically have a body, but it may.

Defined in HTTP/1.1.

B.2.3 202 Accepted

202 Accepted was defined for operations that are requested now but may not take place until later, such as documents submitted to an acceptance process that takes human intervention. Neither HTTP nor WebDAV commonly uses this.

Defined in HTTP/1.1.

B.2.4 203 Non-Authoritative Information

203 Non-Authoritative Information can replace 200 OK when the server might not be responding with the most up-to-date and correct resource body or headers. This is not frequently seen in practice.

Defined in HTTP/1.1.

B.2.5 204 No Content

204 No Content is a basic success code, like 200 OK, but the response has no body. This could be the case, for example, where a GET request is issued for a resource that exists but has an empty body. It is used more commonly in WebDAV, for success responses to methods like COPY and MOVE, where there is no information to be returned in the body.

Defined in HTTP/1.1.

B.2.6 205 Reset Content

205 Reset Content is intended to be used when a server has accepted some input on a resource and the client should refresh its view of that resource as a result. It could theoretically be very useful in submission of Web forms, but it is not used in practice.

Defined in HTTP/1.1.

B.2.7 206 Partial Content

200 Partial Content is used very much like the 200 OK status code, except that it is used when not all the available information was returned. For example, the client could request only the first 1000 bytes of a page using the Accept-Range header, and this response would indicate a successful fulfillment of that partial request.

Defined in HTTP/1.1.

B.2.8 207 Multi-Status

207 Multi-Status responses indicate that the response contains one or more response codes inside its body text. These response codes may refer to multiple resources, with the URLs to those resources also inside the body text. This is most useful in responding to requests that address multiple resources.

Many WebDAV servers return 207 Multi-Status even when only one status code is in the body. For example, the server may consistently prepare 207 Multi-Status bodies for every PROPFIND response, in case there is a need for more than one status code. Even when only one status code is required, the 207 Multi-Status response is already prepared and might as well be sent.

Defined in WebDAV.