[Cosmo-dev] Cosmo and Scooby URLs

Mikeal Rogers mikeal at osafoundation.org
Wed Jun 21 10:08:19 PDT 2006


Thanks Lisa,

We did update this proposal providing a simpler solution which  
returns 301 to the relevant URL rather than returning the format it  
believes the client wants the data in. In the case that we don't know  
the User-Agent we return a 301 to scooby.

With this solution once a client has gotten to where it want's to go  
(web client gets to /scooby/resource/?ticket, or chandler gets to / 
dav/resource/?ticket) it would store the url to it's relevant sharing  
format.

> But when one browser version changes and adds a feature that the  
> other had before, that approach is mal-adaptable.  It's prone to  
> bugs -- even if the developer catches all the different cases (not  
> just Netscape and IE; what about Opera), the "else" case is  
> typically a mishmash of things that don't really behave the same.   
> Keeping a server up-to-date with User-Agent changes is hard.   
> Handling cases where the client upgrades it's functionality and  
> FORGETS to change the User-Agent is impossible.

Your point about end users custom changing their User-Agents was  
brought up in discussion with John and Bobby but what we figured was  
that bending over backwards to find a solution for people who hack  
their clients was a little out of scope.

On the issue of changing versions I know exactly what you mean but I  
don't think it's an issue here. At RealNetworks we had huge issues  
with this, we were supporting specifically tested client versions  
with an array of different features via RTSP on a per client version  
basis and that was a huge problem for years and caused us nothing put  
pain. But, in this case we aren't even looking at the client version  
number, we're saying that all Mozilla/Firefox User-Agents get a 301  
to /scooby/resource?ticket= , and ALL chandler User-Agents get a 301  
to /dav/resource/?ticket= , so I don't see it being a problem. If we  
were distinguishing a feature set within a sharing format, for  
instance our calatom format gets a new version and we want to only  
send the new feature set if the client advertises support for it --  
this could be handled in the /calatom/resource/?ticket= space with  
what ever convention seems to be used by the calatom client community.

I also want to re-iterate that ALL unknown UserAgents will get a 301  
to /scooby/resource/?ticket= , and part of the 0.3 plan is for scooby  
is to present the user with the calendar and to show subscribe links  
to all the available sharing formats of that resource. As you said,  
in the end the best we can do in most cases is direct users to a page  
where they can get an URL to the format they want.

I understand the sad history of User-Agent discrimination but I think  
three factors make us dodge 99% of the issues involved;
1) We aren't returning the resource in a different format, just a 301  
to that resource in the sharing format that client wants it in.
2) We have no intention, and I will strongly discourage,  
discrimination based on client version
and 3) The fallback is always to send people to scooby, which  
presents users with all sharing format options

I think the only case we aren't ready for is if an unknown client  
somehow gets an http url and doesn't know how to display web pages.  
In which case which ever client received the url gives http links to  
a non-web browser.

-Mikeal

On Jun 21, 2006, at 8:25 AM, Lisa Dusseault wrote:

>
> On Jun 16, 2006, at 5:16 PM, Mikeal Rogers wrote:
>
>> Ok, I thought of another way to do this that will satisfy everyone.
>>
>> Since it's so lost in the thread here is what bobby initially  
>> suggested:
>>
>> <link rel="alternate" type="application/atom+xml" title="Home  
>> Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/ 
>> HomeCalendar" />
>> <link rel="alternate" type="application/rss+xml" title="Home  
>> Calendar (RSS)" href="http://cosmo-demo.osaf.org/rss/bobby/ 
>> HomeCalendar" />
>> <link rel="alternate" type="application/caldav" title="Home  
>> Calendar (CalDAV)" href="http://cosmo-demo.osaf.org/dav/bobby/ 
>> HomeCalendar" />
>> <link rel="alternate" type="application/webcal" title="Home  
>> Calendar (Webcal)" href="http://cosmo-demo.osaf.org/webcal/bobby/ 
>> HomeCalendar" />
>>
>> Instead of forwarding requests from one app to another, or merging  
>> them, let's just create another link in cosmo.
>>
>> <link rel="alternate" type="application/magic" title="Home  
>> Calendar (Magic)" href="http://cosmo-demo.osaf.org/magic/bobby/ 
>> HomeCalendar" />
>>
>> In this space we can implement, to the best of our ability,  
>> interop with all clients via one URL. We can do a mix of Accept  
>> and User-Agent headers to interop with as many clients as possible  
>> and implement them on a client by client basis. Then the url still  
>> states what it's purpose is, and we get out of this multi-protocol  
>> interop scenario for the 'default' behavior of a root cosmo url.
>
> Using User-Agent headers for the HTTP server to discriminate  
> between clients has a sad history.  This was done in the 90s with  
> Web sites and regular browsers, which caused some browsers to try  
> to pretend to be other browsers by mimicking their User-Agent  
> strings.  (Some Web browsers even let you configure exactly what  
> text goes in the User-Agent string!).   Thus the approach taken by  
> servers was quickly made useless by clients.
>
> It's just too broad a brush, anyway.  It seems simple to start out:  
> "If the client is Netscape, use this tag; if it's IE use that  
> tag".  But when one browser version changes and adds a feature that  
> the other had before, that approach is mal-adaptable.  It's prone  
> to bugs -- even if the developer catches all the different cases  
> (not just Netscape and IE; what about Opera), the "else" case is  
> typically a mishmash of things that don't really behave the same.   
> Keeping a server up-to-date with User-Agent changes is hard.   
> Handling cases where the client upgrades it's functionality and  
> FORGETS to change the User-Agent is impossible.
>
> We've been having lots of discussion on some IETF lists about what  
> are the feasible ways to shift users from plain web browsing to  
> some more advanced set of features.  There are two and a half ways  
> that work in practice:
>  - A new scheme, like webcal, makes the browser look up a scheme  
> handler application.  This approach is discouraged by the Technical  
> Architecture Group of the W3C (with certain caveats that don't  
> apply here) and I agree with that position.  It suffers from all  
> the problems of the other approaches and additionally with scheme  
> collision risks and interoperability problems.
>  - A new MIME type, like text/icalendar, makes the browser look up  
> an appropriate document handler application.  For a brand new MIME  
> type, the user often has to figure out, the first time they see  
> that MIME type, which application to launch.  So this still  
> requires the user to know what application to launch.  See for  
> example <http://www.ietf.org/internet-drafts/draft-reschke-webdav- 
> mount-04.txt>.
>  - Microformats sometimes works: the HTML markup contains not only  
> a link, but also a machine-readable annotation on the link saying  
> what kind of link it is.  This requires browser extensions to  
> handle, today.  It may be possible, in the future, to have a  
> general microformat approach for "link type" that would allow  
> creation of new types by developers of new applications without  
> requiring browser upgrade/extension.  But even so, it would still  
> require user intervention, at first sight of a new link type, to  
> say what application was capable of handling the new link type.
>
> There are other ways that were designed to work for this purpose  
> but don't due to Web browser extensibility paradigm limitaitons:
>  - The "Allow" header was for the server to advertise in an OPTIONS  
> response, what methods worked on a resource. E.g. seeing PROPFIND  
> there means that the client can then PROPFIND the 'resourcetype'  
> property.  The problem: Browsers don't investigate the OPTIONS  of  
> a resource, and if they do, don't interpret the results in a way  
> that would shift the user to the new functionality.
>  - The "Accept" header was for the client to advertise what MIME  
> types it could handle.  Presumably if a new "application/caldav"  
> type were invented and advertised, the client could advertise it,  
> the server could notice it and realize that the user could be  
> shifted to the higher functionality by returning the appropriate  
> MIME type, yay.  But browsers don't offer an extension point for  
> new applications to say "please, go ahead and offer this in the  
> Accept header".  You'd have to write a FireFox extension to do that  
> (not to mention the other browsers)
>  - Any other response header!  The server can send any response  
> header it likes, in OPTIONS or any other response.  E.g. every GET  
> response to a calendar URL could have a "PLEASE-USE-CALDAV: T"  
> header.  The browser would ignore it.  Only a plugin would allow  
> the browser to notice it.
>  - Any other request header!  The client could add any number of  
> request headers to any method request.  Again, today, this would  
> require the browser to be upgraded.
>
> There is more prior art on this kind of problem than you can  
> imagine, and no usable and robust solution has emerged.  Until OSAF  
> gains the ability to seriously change browser extensibility  
> paradigms, we're limited to the same kind of hacks other people  
> have used.  We can offer a list of URLs somewhere (in email or on a  
> Web page) and some annotations on those URLs.  A user-readable  
> annotation for each URL is required (e.g. "this URL is for CalDAV  
> applications").  A machine-readable annotation on each URL is a  
> nice gesture of hope for improvement but mostly useless today.
>
> Lisa
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list