A webapp I've been developing allows users to upload and download a type of file which is meant to be treated as an opaque blob. My app serves it up with a file extension not commonly used for any other purpose, as well as specifying that its MIME Content-Type is application/octet-stream.
Internally, the file is a simple Zip archive containing a single compressed file. What I've found is that IE6 apparently inspects the content of the file, determines that it's a Zip archive, and "helpfully" saves it with an additional ".zip" extension. Unbelievable!
As I mentioned, this file is meant to be opaque, and we don't want users to be poking around inside the file--not because it's dangerous or contains sensitive information or anything, we just don't want to confuse them. I suggested prepending the Zip content with a magic number to prevent IE6 from recognizing it, but my manager says he'd prefer it if the file content could remain unchanged, so that knowledgeable people can rename the file and examine its contents as a zip archive, if necessary.
Is there any way to tell IE6 to keep its mitts off of the file? Or any alternative approach at all? (Alas, just not supporting IE6 at all is not an option.)
Incidentally, IE7 respects the file's name, but still identifies it as a Zip archive in the download dialog. That's better than IE6, but still less than ideal.
Short answer: Add correct MIME types to you web server so IE6 doesn't guess the file type.
Long Answer:
My work had a similar problem with Microsoft PowerPoint files.
.ppt vs .pps - Which are identical files with different extensions. We wanted the user to view a show (.pps) but IE6 kept changing it to .ppt. It changed the extention because the users machine had PowerPoint installed and understood that the file "looked" like a . ppt. Don't understand why not .pps.
The problem, besides IE6, was that our web server (IIS) was not aware of either MIME types for .pps or .ppt. So we had to add the correct MIME types so the server would not deliver them as "application/octet-stream". I understand that by using "application/octet-stream" IE6 will try to guess the MIME type.
So we added:
.pps = "application/vnd.ms-powerpoint"
.ppt = "application/vnd.ms-powerpoint"
Now it works fine with IE6.
I hope this helps solve your problem.
use this header flag: Content-Disposition: attachment; filename="yourfilename.extension"
This is a known problem, and the only solution is to edit the client computer's registry, which I'm sure doesn't help you a lot.
Related
I have a local markdown file containing several links and I want that links head to local file like pdf.
I use the following syntax:
[my link](file:///C:/my_file.pdf)
But when I open my markdown file into a Firefox page and click on the link, nothing happens.
What exactly have I missed? Is it possible to open local file?
None of the answers worked for me. But inspired in BarryPye's answer I found out it works when using relative paths!
# Contents from the '/media/user/README_1.md' markdown file:
Read more [here](./README_2.md) # It works!
Read more [here](file:///media/user/README_2.md) # Doesn't work
Read more [here](/media/user/README_2.md) # Doesn't work
How are you opening the rendered Markdown?
If you host it over HTTP, i.e. you access it via http:// or https://, most modern browsers will refuse to open local links, e.g. with file://. This is a security feature:
For security purposes, Mozilla applications block links to local files (and directories) from remote files. This includes linking to files on your hard drive, on mapped network drives, and accessible via Uniform Naming Convention (UNC) paths. This prevents a number of unpleasant possibilities, including:
Allowing sites to detect your operating system by checking default installation paths
Allowing sites to exploit system vulnerabilities (e.g., C:\con\con in Windows 95/98)
Allowing sites to detect browser preferences or read sensitive data
There are some workarounds listed on that page, but my recommendation is to avoid doing this if you can.
You link to a local file the same way you link to local images. Here is an example to link to file start_caQtDM_7id.sh in the same directory as the markdown source:
After messing around with #BringBackCommodore64 answer I figured it out
[link](file:///d:/absolute.md) # absolute filesystem path
[link](./relative1.md) # relative to opened file
[link](/relativeToProject.md) # relative to opened project
All of them tested in Visual Studio Code and working,
Note: The absolute and relative to opened project path work in editor but don't work in markdown preview mode!
If you have spaces in the filename, try these:
[file](./file%20with%20spaces.md)
[file](<./file with spaces.md>)
First one seems more reliable
This is a old question, but to me it still doesn't seem to have a complete answer to the OP's question. The chosen answer about security being the possible issue is actually often not the problem when using the Firefox 'Markdown Viewer' plug-in in my experience. Also, the OP seems to be using MS-Windows, so there is the added issue of specifying different drives.
So, here is a little more complete yet simple answer for the 'Markdown Viewer' plug-in on Windows (and other Markdown renderers I've seen): just enter the local path as you would normally, and if it is an absolute path make sure to start it with a slash. So:
[a relative link](../../some/dir/filename.md)
[Link to file in another dir on same drive](/another/dir/filename.md)
[Link to file in another dir on a different drive](/D:/dir/filename.md)
That last one was probably what the OP was looking for given their example.
Note this can also be used to display directories rather than files.
Though late, I hope this helps!
Thank you drifty0pine!
The first solution, it´s works!
[a relative link](../../some/dir/filename.md)
[Link to file in another dir on same drive](/another/dir/filename.md)
[Link to file in another dir on a different drive](/D:/dir/filename.md)
but I had need put more ../ until the folder where was my file, like this:
[FileToOpen](../../../../folderW/folderX/folderY/folderZ/FileToOpen.txt)
If the file is in the same directory as the one where the .md is, then just putting [Click here](MY-FILE.md) should work.
Otherwise, can create a path from the root directory of the project. So if the entire project/git-repo root directory is called 'my-app', and one wants to point to my-app/client/read-me.md, then try [My hyperlink](/client/read-me.md).
At least works from Chrome.
I have a PHP script that I use to download different types of files (PDF, JPEG, RAR end other). Works great, however I noticed an issue there with the MIME-type.
Is there a universal MIME-type I can safely use for "general purpose"? I am thinking of application/octet-stream for all file types.
Or should I do the MIME for each file type individually?
It's supposed to deliver downloads, it's not important to open the files in apps directly.
If you just want to deliver files and don't care about the type of application needed to open it, then it's safe to specify the file mime type as application/octet-stream. However you should specify that it should be saved and should not be attempted to be opened inline within the browser.
you should specify the header as:
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="file.png"
It informs the browser (or the client application) that the file should be downloaded and should not be attempted to be opened inline.
I'm trying to send the content of an Open Office XML file in the response but I can't get the browser to recognize the file and open it with word. It keeps opening it as it was an XML file. I've tried setting the content type to both application/msword and application/vnd.openxmlformats-officedocument.wordprocessingml.document, I've also tried setting the extension to doc and docx, but nothing seems to work.
It sounds like you may be confusing "Open Office" documents with MS Office "Open XML" documents.
The former is a truly open standard (OpenDocument), which can be a single XML file, but is typically a Zipped archive of xml files and binary attachments.
The latter is a similar, but different format, that has been through the standardization process (it is an official ECMA standard), but which has gotten little adoption outside of the MS Office suite. The standardization process was very political - I'll leave it to you to look it up if you are interested.
MS Word, since 2007 SP2 can open OpenDocument (Open Office) .odt files, but I don't think that it works with the single-xml format.
So, try the .odt format.
Also, be aware that Internet Explorer tends to ignore MIME Type, and uses the file extension instead. So you should set the correct MIME Type: application/vnd.oasis.opendocument.text
and set the file name to something ending in ".odt"
I really want to know what the XAP file on Windows Phone 7 is; how important it is; and how I can create it. Could you help me?
XAP is the application package - it is the distributable unit that allows you to install the application on a device (or emulator). Basically, it is a ZIP file with a different extension. If you change XAP to ZIP, you'll be able to read its contents fairly easy.
The XAP file format was inherited from standard Silverlight, and since WP7 is built around the same fundamental core, the file format remained unchanged.
Here is a pretty good description of what it does (remember, that even though it talks about Silverlight, the same main idea applies to WP7):
http://beyondrelational.com/blogs/dinesh/archive/2010/08/18/what-is-xap-file.aspx
In addition to Dennis' excellent post, one other thing about a XAP file - it's a ZIP file - so if you want to look inside one, then just rename it to .zip and then open it using a normal ZIP browser (e.g Windows explorer)
Is there any archive format that offers the following:
be digitally sign-able with a digital certificate from a trusted source like Verisign - for preventing changes to the file (I am not referring to read only, but in case the file was changed it should no longer be signed telling the user this is not the original file)
be stream-able - be able to be opened even if not all of the content has been transferred (also not strictly linearly)
be "readable" - be able to read the data without extracting to a temporary folder (AFAIK if you open a file in a zip archive it is extracted first, and this stays true even for zip based formats like OOXML. This is not what I want)
be portable - support on at least Windows, Linux and Mac OS X is a must, or at least future support
be free of patents - Be open source - also preferably a license that allows commercial use(as far as i know GPL a share-alike license so it doesn't allow commercial use, BSD on the other hand allows it)
Note: Though it may come in handy eventually I can not think right now of a scenario that would require both point 1 and point 2 simultaneously. Or lets leave it a be able to check the signature only when the whole file was downloaded.
I am not interested in:
being able to be compressed
being supported on legacy systems
Does any existing archive format fit this description (tar evolutions like DAR and pax come to mind) ?
If there is, are there programing libraries available for the above mentioned OSs?
If not, would it be hard to create such a thing?
Usage scenario:
I want to use this to create a new media container.
Current media containers contain the audio, video and subtitle streams directly.
Matroska, currently the most advanced container, has supplementary features like attachments and menus.
The menu functionality however is not implemented and very limited.
What I want to create is one level higher.
I want to create a file similar in a way to OOXML.
Also all of the menuing should be done in web technologies like HTML5 (as it is now the tag allows for any kind of codec to be used) and CSS.
Also just like you have holograms on dvds to prove the authenticity I want to create a sign-able file
Research notes:
Before asking this question I stumbled uppon this:
Whats the best way digitally sign a zip file for download using .Net
While detached signing would be feasable for the individual files contained in this archive it is not an ellegant solution for the archive file. Not end user friendly.End users should be able to doubleclick the file to open it in a media player like VLC, and see a message that the file is legit (just like you see in a browser if the page is transmitted with SSL through HTTPS or not)
EDIT: clarified point 5
EDIT 2: added a note to clarify point 1 and 2
EDIT 3: added usage scenario
EDIT 4: added research notes section
P.S.: This is my first question on StackOverflow
I doubt that you find such format out of the box. I understand how such solution can be built with help of our SolFS, but SolFS doesn't have built-in signing (you can add signing easily).