[DAS2] Re: New problem with content-type header in DAS/2 server responses!

[Lincoln Stein]

Well, I give up arguing this one and will go with the way Andrew wants to do 
it. Therefore I propose the following rules:

	1) Return the HTTP 404 error for the case that any component of the DAS2 path
	is invalid. This would apply to the following situations:

		Bad namespace
		Bad data source
		Unknown object ID

	2) Return HTTP 301 and 302 redirects when the requested object has
moved.

	3) Return HTTP 403 (forbidden) for no-lock errors.

	4) Return HTTP 500 when the server crashes.

For all errors there should be a text/x-das-error entity returned that 
describes the error in more detail. 

Lincoln
	


On Thursday 10 November 2005 04:45 pm, Andrew Dalke wrote:
> Further refining this from today's phone meeting
>
> Ed:
> > For a user (let's call her Varla) using IE, the browser will intercept
> > some error codes and present her with some IE-specific garbage,
> > throwing away any content that was sent back in addition to the error
> > code.
>
> The case Ed came across was from an in-house group using a Windows call
> out to IE as a background process to fetch a web page.  In that case
> (as I understand it) it would convert HTTP error responses into its own
> error messages.
>
> Ed couldn't during the conversation recall if it was possible to
> get ahold of the error code at all.  Did they have to parse the output?
>
> > Even for a user (Marla this time) using IGB, firewalls and/or caching
> > and/or apache port-forwarding mechanisms can throw out anything with a
> > status code in the error range.
>
> 404 gets through, yes?
>
> All of those are supposed to be transparent to error codes, or at the
> very least translate them from (say) 404 to 400.
>
> Can anyone point me to some reports of one of these mishaps?
>
> We definitely need to have some tie-ins with the HTTP error codes.
> Consider these two implementations for getting
>
> http://example.com/das2/genome/dazypus/1.43/
>
> (Note the typo "dazypus" -> "dasypus")
>
> A) One system might have all "/das2" URLs forwarded to a DAS server.
>
> B) Another might have a handler only for "/das2/genome/dasypus" and
> let Apache do the rest.
>
> In case A) the DAS server sees that the given resource doesn't exist.
> It needs to return an error.  It can return either "200 Ok" followed
> by a DAS error payload, or return a "404 Not Found" at the HTTP level.
>
> In case B) the request never gets to the DAS handler because
> of the typo.  Apache sees there's nothing for the resource so returns
> a "404 Not Found".
>
> The client code is easier if it can check the HTTP error code and
> stop on failure.  This means it's best for case A) for the DAS/2
> server to return an HTTP error code of 404, and perhaps an optional
> ignorable payload.
>
> > (I did test having the NetAffx DAS server send HTTP status codes, and
> > I did have problems with that in IGB, though I've forgotten the
> > specifics.  It was about a year ago....)
>
> Do you have the specifics perhaps in an old email somewhere?
>
> 					Andrew
> 					dalke at dalkescientific.com
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/das2

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
FOR URGENT MESSAGES & SCHEDULING, 
PLEASE CONTACT MY ASSISTANT, 
SANDRA MICHELSEN, AT michelse at cshl.edu