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

[Andrew Dalke]

My apologies for not tracking what's been going on in the last few
months.  I'm back now and have time for the next few months to work
on things.

So I'll start with this exchange.  I can't find the discussion in the
mailing list history.

Why the decision to use "text/xml" for all xml responses?  I read it
it is so "web browsers can 'just work'".

What are they supposed to do?  Display the XML as some sort of tree
structure?  Is that the only thing?

One thing Allen and I talked about, and he tested, was the ability to
insert a stylesheet declaration in the XML.  Is this part of the
reason to switch to using "text/xml"?

Is there anything I'm missing?

Since it looks like I'm going to be more in charge of the spec 
development,
I would like to start collecting use cases and recording these sorts of
decisions.

I think having different content-types is an important feature.  For
example, it lets a DAS browser figure out what it's looking at before
doing any parsing.  Here's my use case.

I want someone to send an email to someone else along the lines of
   "What do you think about http://blah.blah/das/genome/blah/blah"
with the URL of the object included in the email.

Paste that into a DAS browser and it should be able to figure out that
this is a sequence, a feature, a whatever.  With the old content-types
there was enough information to do that right away.  With this new
one a DAS browser needs to parse the XML to figure out what's in it.
Autodetection of XML formats?  I don't want to go there.

That's also the reason for Gregg's opposition.


You (Allen) and Lincoln, on the other hand, want that user to be able to
go to a web browser and paste the URL in, to get a basic idea of what's
there.

I think that's also important.

I think there are other solutions.  One is "if the server sees a web
browser then return the XML data streams as a 'text/xml'".

For example:
   if "Mozilla" in headers["User-Agent"]:
      ... this is IE, Mozilla, Firefox, and a few others ..

That catches most of the browsers anyone here cares about.  As
another solution, look at the "Accept" header sent by the browser.
Here's what Firefox sends:

Accept: text/xml,application/xml,application/xhtml+xml,text/html;
    q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5'

Here's Safari and "links" (a text browser):

Accept: */*

Another rule them might be

if asking_for_xml_format and "*/*" in headers["Accept"]:
     ... return it as "text/xml" ...

Though a better version is to make sure the client doesn't know about
the expected content type:


if asking_for_xml_format:
    return_content_type = ... whatever is appropriate ...

    if (return_content_type not in headers["Accept"]
        and "*/*" in headers["Accept"]):

           return_content_type = "text/xml"
           .... optionally insert style sheet ....



Another solution is to send a "what kind of DAS object are you?" request
to the URL (eg, tack on a ? query or tell the server that the client 
will
"Accept: application/x-das-autodiscovery").


I think that's clumsy, but I mention it as another way to support
both DAS client app and human browser requests of the same URL.


>> From: Allen Day <allenday at ucla.edu>

>> Looks like the cache server.  FYI, I have updated the server to use 
>> all
>> "text/xml" Content-Type for all xml response types.  This was 
>> approved by
>> Lincoln so that web browsers could be pointed at the das server and 
>> "just
>> work".  I thought these changes had already made their way into the 
>> spec,
>> but apparently not.

>> On Fri, 28 Oct 2005, Helt,Gregg wrote:
>>> But according to the spec the content type header needs to be:
>>> Content-Type: text/x-das-features+xml
>>> I'm using this in the IGB DAS/2 client to parse responses based on 
>>> the
>>> content type.  With "text/plain; charset=UTF-8" IGB doesn't know what
>>> parser to use and gives up.  So right now I can't visualize 
>>> annotations
>>> from the biopackages server.  I'm pretty sure the server was setting 
>>> the
>>> content-type header correctly on Wednesday -- did anything change 
>>> since
>>> then that could be causing this?  Could the server-side cache be 
>>> doing
>>> this for some reason?

					Andrew
					dalke at dalkescientific.com