[DAS2] mtg topics for Nov 28

[Andrew Dalke]

Ed:
> 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 was a two-part problem:
   - identifying in client code that a given error occured
   - extracting the payload when the error occurred

As far as I can tell, the problem you are concerned about is
the second part.

Personally I don't want an application/x-das-error+xml return
document.  Several others do.  Thing is, when Gregg asked
if anyone used the DAS/1 error codes for anything other than
"there was an error", no one said anything.  I could hear the
proverbial crickets chirping (or in my case, snow falling).

I am convinced that the actual error content will be server
implementation specific and as such non-portable across
clients.  I will flesh out a document type for this then
ask Thomas, Lincoln etc. to provide a list of defined
error code extensions that their servers will return.

It's likely they'll not be able to agree on it, because
their code will do different styles of error checking.

I'll also dodge the whole mess by saying that the error
document payload is optional, so clients are highly unlikely
to read it for anything meaningful.  (Except perhaps some
text shunted to the user.)

That makes more work in the spec implementation for something
I can almost guarantee will be ignored by DAS clients.

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

I don't understand how the old one would be a problem in the
web clients I'm familiar with.  It should be:

   send request to server
       get 302 "moved temporarily" response along with new URL
   repeat until no redirect or reached max redirect limit
   request new URL
       get headers/payload back

The redirects shouldn't affect the real response code, which
would be the last in the chain.  If it did, it would also
affect 404 and 200 responses.

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

I know that fear.  I've had intermediate web caches misconfigured
which cached anything HTML page for an hour, making me unable
to edit my web site and see the changes.

That was with a normal 200 response code, so likely misconfigured
caches will affect other response codes.  But what's there to
do about that?  What's the error rate?  We're using normal HTTP
and if a web cache breaks for us - we aren't doing anything
fancy; no content-negotiation, no 'If-Modified-Since', etc - then
it will break for anyone doing HTTP.  That's anyone exchanging
HTML, sending RSS, etc.


					Andrew
					dalke at dalkescientific.com