Hi,

I set quicktime files to be set to view only not download.  For some reason when i click on quicktime files in DMX4 the movies do not play in the browser.  I have this same problem with shockwave files.  I do not have this problem with pdf's however.  Can someone please help?

 

Thanks,

Scott

Hi,

Is your web server configured to serve those mime types? If not, that is the most likely cause.

Hope that helps.

Rob Ralston

Hello,

I am having the same issue on the trial version. I have triple checked the mime settings on my web server and in document exchange. On the web server if I simply put a quicktime .mov file in the root of the website and type in the url such has http://localhost/test.mov - it plays just fine. If I embed it into a web page it plays just fine, but if I set the document exchange to only allow the view option - I get a bunch of garbage in my browser. If I set to allow to download the file, then it will ask to confirm the download and then the file will open from my local system just fine.

What we want to do in my case is to prevent the users from having a copy of the file saved locally on their drive - or at least have it obfuscated enough that it cannot be easily identified. Please help - I like your product, but unless I can resolve this issue I cannot use the software.

Thanks,
Brian

I'll look into this. You don't have any compression switched on do you?
Peter

Compression is not turned on at all. In addition if you monitor the traffic to/from the server using a utility like fiddler, on a PDF (which works) you see traffic delivered to the client in this order:

~headers
filename.pdf

When you click to view a Quicktime file set to view, this is what you see:

filename.mov
~headers

Not sure it this helps - but at least it shows a different pattern. I am not sure how document exchange sends a file to the browser when set to view - but it would seem maybe it is trying to stream the video and without a streaming server or something of that nature, the browser does not know how to render it. Have you or has anyone successfully set a .mov file to view only and actually had it work? We have tried Firefox and IE 7 on both Vista, Server 2003, and XP. We have also downloaded the latest Quicktime software from Apple.

Thanks!

Thanks. This helps. I'm on the verge of running these tests myself.

Peter

OK, I've spent half a day on this issue and have not been able to resolve it. I have tried changing the order of the headers and changing which headers are sent out, but my power is, alas, limited. I find that .net actually overrides some of this. So the Content-Type is never sent at the beginning, but only after Content-Length

This is a successful request (directly http://...whatever/somemovie.mov):
HTTP/1.1 200 OK
Content-Type: video/quicktime
Last-Modified: Sun, 06 Oct 2002 17:38:20 GMT
Accept-Ranges: bytes
ETag: "0e2e295f6dc21:0"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Mon, 10 Mar 2008 10:08:44 GMT
Content-Length: 5420732

And this is a failed one (through asp.net):
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 5420732
Content-Type: video/quicktime
Last-Modified: Mon, 10 Mar 2008 10:43:27 GMT
Accept-Ranges: bytes
ETag: "file_20080310_104326_RsT_0.resources"
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 10 Mar 2008 10:47:01 GMT

Note that I don't think the http specifications allow browsers to change behavior subject to header order. I believe the order is specified as arbitrary. But if you do a little Googling on server files, you'll see it is a minefield, with each browser manufacturer doing what he/she believes is best. Not cool for programmers.

Note: I did verify the bytes being transmitted and they matched.

I'll devote more time to this in due course. But if the worst comes to the worst I'd have to write my own handler (i.e. full control over what goes out over the wire to the client). This is not an attractive prospect. It means more potential points of failure and a more complex installation.

Peter

OK, maybe this helps.  When someone with a MAC clicks on a quicktime file it works great but when someone using IE7 double clicks the quictime file they get a page full of strange characters.  Any ideas?

 

THanks,

Scott

It has to be related to the actual QuickTime plugin for IE. I cannot see any other candidate. Like I mentioned earlier, the headers are all there and AFAIK the order should not make a difference. From what we know it looks like the IE plugin distinguishes the header order. I cannot determine if this is MS fault or Apple. I'm sure they'll blame one another. One surprising thing though: I could not find mention of anyone else experiencing this when Googling (if you can, please paste that here). This should happen every time someone is trying to send a bytestream that mimics being a mov file over the internet to a browser using .net.

Peter