From Media Fragments Working Group Wiki
This page is for discussing issues around the TC. Each section should have a responsible person (typically the one who raised an issue or has an action on it).
HTTP Status Code for TC returning EMPTY
Responsible: Michael, as of 2009-05-13 telecon
The MF WG agreed that an 'empty response' (such as found in TC0002-0006) is not an error, hence no 404 status code MUST be send by the origin server. The WG intends to allow to create a recoverable situation and hence is looking for alternative HTTP status codes in this situation.
As this is a situation where the client seems to have erred, 4xx class of status codes should be used; the options read as follows:
406 Not Acceptable
406 Not Acceptable is defined as:
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
412 Precondition Failed
412 Precondition Failed is defined as:
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
416 Requested Range Not Satisfiable
416 Requested Range Not Satisfiable is defined as:
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field.
In case an 'empty response' (such as found in TC0002-0006) occurs, the origin server MUST send an HTTP 416 status code if and only if the fragment range was given in an HTTP Range request header, otherwise a HTTP 406 status code MUST be send.
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
Yves' response regarding this discussion pretty much decided the issue (see his reply).