Skip to main content

HTTP Status Code 208 - ALREADY REPORTED (WebDAV)

Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.

For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.

HTTP Status Code 208 - ALREADY REPORTED (WebDAV)

Note that the 208 status will only occur for "Depth: infinity" requests, and that it is of particular importance when the multiple collection bindings cause a bind loop.

A client can request the DAV:resource-id property in a PROPFIND request to guarantee that they can accurately reconstruct the binding structure of a collection with multiple bindings to a single resource.

For backward compatibility with clients not aware of the 208 status code appearing in multistatus response bodies, it SHOULD NOT be used unless the client has signaled support for this specification using the "DAV" request header. Instead, a 508 Loop Detected status should be returned when a binding loop is discovered. This allows the server to return the 508 as the top-level return status, if it discovers it before it started the response, or in the middle of a multistatus, if it discovers it in the middle of streaming out a multistatus response.

Example: 

>> Request:

   PROPFIND /Coll/ HTTP/1.1
   Host: www.example.com
   Depth: infinity
   DAV: bind
   Content-Type: application/xml; charset="utf-8"
   Content-Length: 152

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:prop>
      <D:displayname/>
      <D:resource-id/>
     </D:prop>
   </D:propfind>

>> Response:

   HTTP/1.1 207 Multi-Status
   Content-Type: application/xml; charset="utf-8"
   Content-Length: 1241

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
       <D:href>http://www.example.com/Coll/</D:href>
       <D:propstat>
         <D:prop>
           <D:displayname>Loop Demo</D:displayname>
           <D:resource-id>
             <D:href
   >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
           </D:resource-id>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>http://www.example.com/Coll/Foo</D:href>
       <D:propstat>
         <D:prop>
           <D:displayname>Bird Inventory</D:displayname>
           <D:resource-id>
             <D:href
   >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf9</D:href>
           </D:resource-id>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>http://www.example.com/Coll/Bar</D:href>
       <D:propstat>
         <D:prop>
           <D:displayname>Loop Demo</D:displayname>
           <D:resource-id>
             <D:href
   >urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf8</D:href>
           </D:resource-id>
         </D:prop>
         <D:status>HTTP/1.1 208 Already Reported</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

Wikipedia
The members of a DAV binding have already been enumerated in a previous reply to this request, and are not being included again.

Comments

Popular posts from this blog

HTTP Status Code 403 - Forbidden

The client does not have access rights to the content, i.e. they are unauthorized, so server is rejecting to give proper response. Unlike 401, the client's identity is known to the server. The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any). If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the req

HTTP Status Code 401 - Unauthorized

Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response. The request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field containing at least one challenge applicable to the target resource. If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information. The request requ

HTTP Status Code: 200 - Ok

The request has succeeded. The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as: GET a representation of the target resource HEAD the same representation as GET, but without the representation data; POST a representation of the status of, or results obtained from, the action; PUT DELETE a representation of the status of the action; OPTIONS a representation of the communications options; TRACE a representation of the request message as received by the end server. Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 No Content instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begin