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

[Andrew Dalke]

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