Macromedia Contribute browser detection

Doesn't output unique string for GET

[heisters]

Hi all,

Not sure if this is the right forum, please redirect me if you think another might provide me with more success.

I need to be able to detect Macromedia Contribute users in my Apache conf in order to do some gentle redirection to make Contribute work with content negotiation. When it does a PUT or a WebDAV GET it kindly identifies itself as "Contribute/3.0". However, when submitting a GET on regular HTTP, Contribute doesn't use a unique user agent ID string. Instead it identifies itself as

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) 

on Windows XP and Mac OS X respectively. DoubleU-Tee-Eff.

So I thought perhaps ".NET CLR 2.0.50727" would be specific to Contribute on Windows. And "AppleWebKit/417.9" without a "Safari" at the end might be specific to Contribute on OS X. However, I've been unable to find any information supporting or denying this hypothesis.

So, any tips on how to proceed? Does anyone perhaps know of a completely other method of determining if the browser is Contribute? Perhaps an idea of how to force Contribute to identify itself correctly?

The Macromedia forums have been less than helpful--they're sparsely populated, and the advanced questions are like "How do I make an administrator the publisher?"--not exactly Apache hacking.

TIA

[encyclo]

"NET CLR 2.0.50727" is the .NET runtime 2.0, and it's not a unique signature to Contribute as I've found it in my stats. Seeing AppleWebKit without Safari is possible as it could be an unofficial build (AppleWebKit is open source). It is a real conundrum you have there, with a regular GET request and what appear to be pretty generic user agent string, your options would appear to be to either force Contribute to send a specific UA, or attempt to bypass or fix the underlying the problem.

What is the specific issue you are having with content negotiation and Contribute? What kind of content negotiation is it (language, media type...)?

[heisters]

There are a lot of bugs in contribute, and I guess this is one of them. My other favorite is a problem with preferences where you can't go back to editing the top group of preferences once you go to any other group. I wonder if they tested Contribute for more than a week before distributing it.

The content negotiation I'm doing is just media type stuff. If Contribute sees a file with an extension it doens't recognize (or none at all, as in this case) it freaks out and says you can't edit that type of file. To complicate matters, it automatically appends "index.php" to any directory listings, so it can edit indices just fine. All the links in the website rely on content negotiation, so they continually point Contribute to files without extensions, which Apache resolves fine, but gets Contribute's panties in a bunch.

At this point the only solution I see is to setup a VirtualServer on port 8080 that uses mod_rewrite to append '.php' to links. However, I'm positive that this will cause problems with links to any non-php files, and I'm not sure how to deal with that.

It's frustrating because I have to setup all sorts of new stuff because of a bug in Contribute. The easiest way to solve this would be if Contribute relied on the MIME type of a file to determine whether it could edit it. The second easiest way would be if there were some sort of control within Contribute to set which files it can edit. (There is an Extensions.txt, but I couldn't get it to accept a null string).

[heisters]

Is there anyway to rewrite a URL based on the MIME type of the target file? So basically, mod_rewrite would make the URL reflect the content negotiator's resolution. What about a mod_perl filter?

[heisters]

I've continued my train of thought over here [webmasterworld.com...] since I think the only way of solving this is by doing some fancy Apache Hack-Fu