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

[Allen Day]

To be even more concise, there are two use cases being presented here:

1) DAS/2 content should be viewable in a web browser, and doing so
requires a HTTP Content-Type header to have value 'text/xml'.

2) DAS/2 content should be viewable in a specialized DAS/2 browser, and be
able to rely on HTTP headers to determine visualization mode, as
XML/DTD/Schema sniffing is undesireable.

The solution proposed in the referenced thread, or perhaps only on a
conference call, is to use the Content-Type header to address (1),
providing information to web browsers, as they are less flexible than a
specialized DAS/2 client.  (2) is addressed using a DAS/2 specific 
X-Das-Content-Type header, e.g.

==================
% GET -e 'http://das.biopackages.net/das/genome/human/17/feature?overlaps=chr22/1000000:2000000;type=SO:mRNA' | head -100
Connection: close
Date: Wed, 09 Nov 2005 02:15:24 GMT
Server: Apache/2.0.51 (Fedora)
Content-Type: text/xml
Expires: Thu, 09 Nov 2006 02:15:24 GMT
Client-Date: Wed, 09 Nov 2005 02:19:16 GMT
Client-Peer: 164.67.183.101:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
X-DAS-Content-Type: text/x-das-feature+xml
X-DAS-Server: GMOD/0.0
X-DAS-Status: 200
X-DAS-Version: DAS/2.0
==================

This also has the added benefit of already being implemented for a few
months.  Are there objections to this solution?

-Allen




On Wed, 9 Nov 2005, Andrew Dalke wrote:

> 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
> 
> _______________________________________________
> DAS2 mailing list
> DAS2 at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/das2
>