vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?)

[Xiaoming Liu]

+1


On Wed, 8 Mar 2006, Daniel Chudnov wrote:

> See below for background.  This thread seems like a lifetime ago
> somehow. :)  I know I said we shouldn't revisit decisions we've already
> made, but it seems best to first consider removing all mentions of
> particular status codes from the normative portion of the spec.
>
> Please vote on this whole change as a full diff; if you don't like
> part of it for any reason, vote it down, and we'll amend for another
> vote.
>
>  -Dan
>
>
> Proposed change:
>
> - Change the last para under How it works which now reads:
>
>   "To minimize the scope of this specification, unAPI uses existing
>   HTTP status codes with the meaning most appropriate for a particular
>   unAPI response. See the section "Notes on HTTP status codes and error
>   handling" below for a detailed summary."
>
>   ...to instead read:
>
>   "unAPI uses the response status codes defined in HTTP [RFC 2616] to
>   indicate the success or failure of an operation.   See the section
>   "Recommended HTTP status codes and error handling (non-normative)"
>   below for suggestions of particularly useful status codes."
>
>   (note: the first line is verbatim from APP.)
>
> - In the UNAPI (no parameters) response section, first para, remove the
>   text:
>
>   "status code should be 200."
>
> - In the UNAPI?uri=URI response section, second para, remove the text:
>
>   "status code should be 300 (Multiple Choices)"
>
> - Retitle the "Notes on HTTP status codes and error handling" to:
>
>   "Recommended HTTP status codes and error handling (non-normative)"
>
>   ...and rewrite its content to say:
>
>   "unAPI defers to the response status codes already defined in HTTP
>   [RFC 2616].  In particular, it is recommended that unAPI implementors
>   utilize the following:
>
>   * 300 Multiple Choices - the UNAPI?uri=URI function
>
>   * 404 Not Found - requests for a URI that is not available on the
>   server
>
>   * 415 Unsupported Media Type - requests for a URI that is available
>   on the server but for a format that is not available for that URI
>
>   Note that this list is provided as a guideline to encourage consistency
>   across implementations.  All HTTP status codes are relevant for any
>   web resource; these status codes are particularly germane for unAPI."
>
>
>
>
>
> Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500:
>> Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700:
>>>
>>> Thanks for catching key point for me. It's really about whether these
>>> status code are recommendation/best practice, or mandatory. I am much
>>> comfortable if we put them as recommendation, therefore not part of
>>> compliance check.
>>
>> Okay, so, I think we're converging on the same point here:  we defer
>> to HTTP itself, but maybe suggest a few particular codes.  Maybe the
>> suggestions are even non-normative, and we don't require specific response
>> codes for "unAPI compliance".
>>
>> Does anyone want to take a stab at rewriting that final bit on HTTP codes?
>
>