• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Help with mime types

Armitage

Banned
We have an in-house app that I want to associate with files available from a website on our intranet. I'm having trouble getting this to work.

I've defined a new mime-type in a .htaccess file in the document root:

AddType application/aero-soap orb

orb is the file extension - ie. myfile.orb

The file is generated on-the-fly by a perl script, it's sent out as follows:

print "Content-Type: application\/aero-soap\nContent-Disposition: attachment\; filename=$conj[0]_$conj[1]_$x.orb\nContent-Length: $size\nContent-Description: SOAP Model\n\n";

print $mfile;

where $mfile contains the string to be output as a file.

But again, Firefox doesn't make the association. Any ideas? How can I tell if Apache is picking up the mime-type from the htaccess file properly?
 
Microsoft's network monitor or other "packet sniffer" apps would let you see what headers the server is actually sending.

Defining a mime type on the server doesn't automatically create a file type association in the browser, that typically must be done in the brower itself by the user or a client-side app.

If the association is working properly in the browser you should be able to open a file in Windows Explorer, "open with" firefox, or with an <a> link from an .htm file on the local hard drive to an .orb file on the local hard drive.

(apologies if you know that already, but your post seems to say you think the server side can do this)
 
Originally posted by: DaveSimmons
Microsoft's network monitor or other "packet sniffer" apps would let you see what headers the server is actually sending.

The konqueror file download dialog shows it as the proper type. But I'm wondering - why does the server have to have a mime-type defined, and you set it in the header that you send back with the file (the perl bit from my first post). It seems that one or the other should be adequate?

Or maybe the server mime-type is only needed when the server is reading an arbitrary file of the disk - since I'm sending it from the script and including the header with the mime-type maybe that's enough.

Except it isn't because it doesn't work 🙁

Defining a mime type on the server doesn't automatically create a file type association in the browser, that typically must be done in the brower itself by the user or a client-side app.

Yep, that's the problem - I download one of them and check the box to tell it to always do this for this type of file. But when I go to do another it doesn't remember - from what I've read this is due to a mime-type issue.

If the association is working properly in the browser you should be able to open a file in Windows Explorer, "open with" firefox, or with an <a> link from an .htm file on the local hard drive to an .orb file on the local hard drive.

Hadn't thought about reading a local file from the HD - I'll try that tomorrow.

(apologies if you know that already, but your post seems to say you think the server side can do this)

Don't assume anything about me & web development 😛
Thanks.
 
Something else you could check with a packet sniffer, is to compare what you send against what is sent by a well-defined application type like a Flash swf.

I remember it taking me a long time to notice that the string in the "boundary" header for multipart/form-data encoding is 2 characters shorter than when it is used in the body of the POST 🙁
 
Back
Top