[DAS2] mtg topics for Nov 28

[Ed Erwin]

Andrew Dalke wrote:
> Here are the spec issues I would like to talk about for today's meeting,
> culled from the last few weeks of emails and phone calls
> 
> 1) DAS Status Code in headers
> 
> The current spec says
> 
>>  X-DAS-Status: XXX status code
>>
>> The list of status codes is similar, but not identical, to those used  
>> by DAS/1:
>>
>> 200 OK, data follows
>> 400 Bad namespace
>> 401 Bad data source
>> 402 Bad data format
>> 403 Unknown object ID
>> 404 Invalid object ID
>> 405 Region coordinate error
>> 406 No lock
>> 407 Access denied
>> 500 Server error
>> 501 Unimplemented feature
> 
> 
> I argued that these are not needed.  Some of them are duplicates with
> HTTP error codes and those which are not can be covered by an error
> code "300" along with an (optional) XML payload.
> 
> The major problem with doing this seems to be in how MS IE handles
> certain error codes.  While IE is not a target browser, MS software
> may use IE as a component for fetching data.  From the link Ed dug
> up, it looks like this won't be a problem.
> 

I'm not going to argue anymore against moving the X-DAS-Status code up 
into the HTTP status code.  I'm willing to try it and see if it works.

But I want to re-iterate why I'm suspicious of this.  I have experience 
trying this in two separate projects and it failed both times.  (Still, 
I think those problems won't occur this time.)

1.  I tried this on a project internally at Affymetrix.  It didn't work 
in this case because the client code was (indirectly) using MS IE code, 
and IE was throwing away the HTTP content when the header had certain 
error codes.  This doesn't bother me much now, though, because I doubt 
many DAS clients will be written that interface with IE, and because I 
now know that you can force IE to keep the HTTP content as long as you 
make sure the content is always at least 512 characters long.  So if we 
ever run into this problem, there is an easy work-around.

2. I tried putting the X-DAS-Status codes into the HTTP status code in 
our internal DAS/1 server about a year ago.  (In DAS/1 they are not 
supposed to be in the HTTP status codes, but I misunderstood the spec.) 
  I ran into problems when I tried that, and that is the main reason I 
objected to trying that in DAS/2.

Unfortunately, I can't remember what those problems were....

The problem might have been:
a) the IGB client didn't understand the status codes because they 
weren't in the expected place.

If this is the case, then the problem was benign, because we are now 
writing new code to support the new spec, so we can make IGB understand 
whatever we want.

b) I use Apache's ".htaccess" files to do some URL re-direction on our 
DAS/1 client machine.

see http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule

It is possible that this was causing the original HTTP status code to be 
replaced with a different one.

I'm currently using the "proxy" form of redirect, which seems to keep 
the status code intact.  Earlier I was using the "redirect" form of 
redirect, which may change the status code to 302.

-----

Based on my experience with apache re-direction, I have a vague fear 
that we may run into cases where firewalls, or html cachers and 
optimizers may mangle the HTTP status codes for some users at some 
point.  But since I have no confirmed evidence that that will happen, I 
have no objection to  going ahead and trying to use HTTP status codes.