W3C home > Mailing lists > Public > public-media-annotation@w3.org > October 2011

Re: follow up on the HTTP status codes for API spec to CR.

From: Thierry MICHEL <tmichel@w3.org>
Date: Wed, 12 Oct 2011 09:11:08 +0200
Message-ID: <4E953D8C.6050804@w3.org>
To: Florian Stegmaier <stegmai@dimis.fim.uni-passau.de>
CC: "Bailer, Werner" <werner.bailer@joanneum.at>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Florian, Werner,

Could you please advocate our response to Yves (or maybe adopt his proposal)
5XX to a request from the client that should trigger a 4XX (missing 
_requested_ property).


We have to move this issue forward, according to the Last Call comment
http://www.w3.org/2006/02/lc-comments-tracker/42786/WD-mediaont-api-1.0-20100608/2556?cid=2556

Thierry

 >

Le 11/10/2011 17:04, Yves Lafon a écrit :
> On Tue, 11 Oct 2011, Thierry MICHEL wrote:
>
>> Yves, Philippe,
>>
>> This is our follow up on the HTTP status codes issue raised during the
>> Transition call of the API spec to CR.
>>
>> The MAWG has discussed this issue and we have come up with a proposal:
>> First let me clarify our analysis:
>>
>> 1- We are not using these status codes as return values of an HTTP
>> request, but as a status in the methods of our API. We think this makes
>> a difference.
>
> Ok, so it means that you are tunnelling pseudo-http over htt, or
> partially subverting real HTTP codes with your in-object status.
>
>> 2- We had a look at the WebDAV spec. WebDAV is an example that defines
>> new status codes beyond those of the original HTTP 1.1 spec (e.g. 507
>> in
>> [1]).
>>
>> RFC 2616 states in section 6.1:
>> "HTTP status codes are extensible. HTTP applications are not required
>> to understand the meaning of all registered status codes, though
>> such
>> understanding is obviously desirable. However, applications MUST
>> understand the class of any status code, as indicated by the first
>> digit, and treat any unrecognized response as being equivalent to
>> the
>> x00 status code of that class, with the exception that an
>> unrecognized response MUST NOT be cached. For example, if an
>> unrecognized status code of 431 is received by the client, it can
>> safely assume that there was something wrong with its request and
>> treat the response as if it had received a 400 status code. In such
>> cases, user agents SHOULD present to the user the entity returned
>> with the response, since that entity is likely to include human-
>> readable information which will explain the unusual status."
>>
>> --> We think that our extension would confirm to this even if it was a
>> real response to an HTTP request. As it is *not an HTTP response*, the
>> issue is even less critical in the group's opinion.
>
> Well, in your case, the WG decided to respond with a 5XX to a request
> from the client that should trigger a 4XX (missing _requested_ property).
>
>>
>> RESOLUTION:
>> -----------
>>
>> We have added the following statement in the API specification [2]
>>
>> [
>> This section introduces a set of status codes for the defined API to
>> indicate the system behavior. As described in section 4.4, the status
>> code is returned as one of the attributes of the Media Annotation
>> object
>> returned by a method call to the API.
>
> Why doing this tunnelling instead of reusing the HTTP response code?
>
>> The status codes follow the scheme of the HTTP/1.1 [HTTP11] status
>> codes, because developers are familiar with it. This choice does not
>> imply any specific link with HTTP, nor are the status codes used as
>> part
>> of the actual HTTP response. Status codes from HTTP/1.1 are used with
>> the same semantics as in [HTTP11] whenever possible, adding specific
>> codes when needed. These specific codes are extensions in conformance
>> with section 6.1 of [HTTP11].
>> ]
>>
>> --------
>>
>> Yves and Philippe could you please confirm that you agree to our
>> resolution. Then we will proceed to Transition to CR.
>>
>> Best,
>>
>> Thierry
>>
>
Received on Wednesday, 12 October 2011 07:11:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 October 2011 07:11:33 GMT