problem readin .swf files

[lorriek]

I recently purchased zoom pro and have had a persistent error when trying to index pages with spider.

here's the error:
Could not download file: http://www.davidbanks.co.uk/beta.swf (Unsupported Content-type)

Any ideas why? I've also attempted to run it on other flash sites I have and get the same error, with different addresses of course.

Many thanks for you help.

[David]

Hmmm. Might be a bug.
We'll investigate it in more detail on tomorrow (Monday).

-------
David

[Ray]

Your site is not returning the proper MIME content-type for SWF files. Since Version 4.2, Zoom now requires the correct content-type to be specified by the web server for files to be indexed appropriately

Your web server is currently returning "application/octet-stream" for SWF files instead of "application/x-shockwave-flash". This is the reason why Zoom is not recognizing the files as a supported format.

If you change the MIME types on your web server (or ask your web host to do so), so that it correctly returns "application/x-shockwave-flash" for SWF files, Zoom should then be able to index these files successfully.

We did note that your HTML page link to the SWF files and they specify the content-type via the EMBED tag. However, Zoom does not currently support the "type=" attribute in the EMBED tag, because it is not considered standard, and it was never defined in the EMBED specifications. In fact, Macromedia recognizes this and warns that it is not the recommended method to specify a SWF file type because it is not supported by many browsers. More information here:
http://www.macromedia.com/cfusion/kn...cfm?id=tn_4151

If you can change the MIME type on the server, this should solve your problem as mentioned.

We could also consider removing "application/octet-stream" from the list of unsupported content types, if this turns out to be a more common problem for users. This would then allow Zoom to resort to determining the type by file extension (".swf") when the content-type specified by the server is not accurate, or incorrect.

Of course, we'll then hear from users that have EXE or other binary files served via a script (eg. download.php) expecting Zoom to skip the file based on the content-type being "application/octet-stream" ... Nonetheless, there are a few other solutions to this, and we'll be looking at changing the way we handle this in a future release.