[gcs-pcs-list] (possible) issue: what to do for redirects?

[Xiaoming Liu]

On Sun, 5 Mar 2006, Daniel Chudnov wrote:

>
>> Here I suggest we have a look atom publishing protocol's approach, see
>> section 5.5 of atom publishing protocol
>> (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt)
>>
>> 5.5  Use of HTTP Response codes
>>
>>    The Atom Protocol uses the response status codes defined in HTTP to
>>    indicate the success or failure of an operation.  Consult the HTTP
>>    specification [RFC2616] for detailed definitions of each status code.
>>    It is RECOMMENDED that entities contained within HTTP 4xx and 5xx
>>    responses include an explanation of the error using natural language.
>>
>> I am prone to Atom's approach.
>
> How is this different from our approach?  In that perhaps we're specifying
> even more than we should?  Or that we should recommend a natural language
> explanation as well?  Sorry if I'm just missing your point here.
>
> We're deferring to HTTP status codes as much as possible, too.

sorry I didn't put my point clearly. My understanding is that APP leaves 
the choice of error processing to implementors, thereforer avoid 
explicitly defining error code in the protocol, e.g. in the previous 
discussion about 406 vs. 415, an implementor can decide either return 
406, 415, or even straight 400.

I am not an APP expert so any explanation is my best guess. I think APP's 
approach has following advantage:

(1) make the implementation simple.
The server and client are not burdened with special eror processing code.

(2) shorten specification.
By defering all error processing to HTTP protocol.

(3) avoid future bloating unapi with error code
look at the HTTP 400/500 series code, several more might be applicable to 
our case, such as 410 (gone) 403 (forbidden) 408 (request timeout), 500 
(server error)  503 (service unavailable), some of these are not 
completely under unapi's control. e.g. a 403 or 503 error might be created 
by apache.

More practically, because most 400/500 errors need human intervene, no 
matter what error code is chosen, a human being has to figure out the 
problem. if so, a natual language explanation is the best choice.

So my proposal is that we literally adopt APP's approach, how to 
define/implementat error code is up to server/client individual choice. An 
advanced server may use up all http 400/500 code, and an advanced client may try to 
interpret all of them. But the bottom line is that a server will generate 
an error code if it believes so, and a client should not silently ignore 
an error code.  So one may choose an advanced or dummy implementation, but 
they are still unapi compliant.

xiaoming