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

[Mike Rylander]

On 3/6/06, Xiaoming Liu <liu_x at lanl.gov> wrote:
> 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.

This may just be me, but "not burdened with special eror processing
code" sounds like the opposite of "programming for failure".  
Programming for failure allows for a consistent user experience across
all implementations and under all conditions, failure or success. 
Admittedly, I too need to take this advice, since my implementation is
just punting when bad things happen.

I think it's fine to build a prototype that doesn't fail gracefully,
but, IMHO, we should actively encourage programmers interested in
implementing unAPI to use a standard set of error codes (and non-error
codes, for that matter) because it promotes cross-implementation
portability, and it ends up making good clients easier to write
because they only have to follow the spec and not know the
implementation quirks of every "major" unAPI server.

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

I think we're already doing this, while also recommending the "best"
code to use in each particular case that we've run into.

> (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.
>

See above -- we are explicitly looking at HTTP, and trying to find the
best, smallest set of error codes to use.

> 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.
>

Like I said, I think this is the spirit of what we're doing today. 
Here in the early stages of protocol and format development, however,
I think it's a good idea to help server admins and implementers pick
the best code for a particular situation.  It may not be difficult for
someone with lots of server side development experience to pick status
codes that make sense (though it's obviously not trivial -- the HTTP
spec is (necessarily) vague), but it certainly wouldn't hurt to give
the "noobs" a helping hand in interpreting the HTTP status code spec. 
If we find that the "recommended status codes" list is indeed bloating
the spec at some point, then I think it should be spun off into an
auxiliary "best practices" document.  But for the time being, having
the knowledge of the "right" way to apply status codes right there at
the bottom of the spec makes creating new implementations easier, and
IMO encourages those new implementations to be more accessible to
existing clients, since these new servers will fail in the same way as
existing servers.

> xiaoming
>

--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org