[Cosmo-dev] Cosmo and Scooby URLs

[Lisa Dusseault]

On Jun 21, 2006, at 1:08 PM, Mikeal Rogers wrote:
>
> 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.

That's not the point.  The point is that people and software  
developers lie with User-Agent strings as soon as they're given a  
reason to do so, and this breaks the server logic.  It's not about  
making stuff work for them -- they're customizing the User-Agent  
string *in order* to make things work for them the hacky way.  It's  
the people who don't customize their User-Agent string that we  
eventually have trouble making things work for.


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

It's more than just changing versions.  In the browser world, IE  
masquerades as Mozilla and is now stuck continuing to do that <http:// 
www.ericgiguere.com/articles/masquerading-your-browser.html>.   
Originally this was done because IE added some feature that  
previously only Mozilla had supported, and there existed servers that  
used the User-Agent string to decide whether to use that feature.  In  
order to compete with Mozilla, IE had to pretend to be Mozilla.

In our case, the similar imaginary example would be if some developer  
wrote a calendar client that supported CalDAV and handle Chandler  
invitations; let's call that application "CloneCal".  The only way  
"CloneCal" can get this 301 redirecting them to the DAV namespace is  
by masquerading as Chandler -- putting the "Chandler" string in their  
User-Agent.

This works for one, and only one, discriminating factor.  Once we use  
this trick, we've blown it.  Because now if Chandler adds support  
for, say, new collection Synch features before CloneCal does, we're  
stuck.  We can't tell CloneCal from Chandler in order to decide  
whether to return collection Synch information or something else.

Again, it's not making things work for CloneCal and its hacky choice  
-- the developers of CloneCal made things work for themselves.  It's  
that we can't stop them from ruining the trick for browsers/clients  
that try to do the right thing.

Lisa