By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,626 Members | 1,424 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,626 IT Pros & Developers. It's quick & easy.

file types & automatic openning...

P: n/a
Mel
when downloading files from my site, when file types are known (i.e *.doc)
browsers open the file for viewing.

is there a way to disable that and just present the save as dialog (same as
for unknown types zip files etc.) ?

thanks
Mel
Jul 20 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
Mel wrote:
when downloading files from my site, when file types are known (i.e *.doc)
browsers open the file for viewing.

is there a way to disable that and just present the save as dialog (same
as for unknown types zip files etc.) ?


The FAQ covers this:

<URL:http://www.htmlhelp.org/faq/html/media.html#force-download>

Also:

<URL:http://www.catb.org/~esr/faqs/smart-questions.html#before>

--
Jim Dabell

Jul 20 '05 #2

P: n/a
Mel wrote:
when downloading files from my site, when file types are known (i.e
*.doc) browsers open the file for viewing.

is there a way to disable that and just present the save as dialog
(same as for unknown types zip files etc.) ?


You can see this :

http://support.microsoft.com/?id=260519

--
Pour me répondre par mail privé, merci de supprimer _NOSPAM_ de mon
adresse.

Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/oe-quotefix/

Jul 20 '05 #3

P: n/a
in post: <news:c8**********@s0b1a68.ssa.gov>
Mel <me**********@ssa.gov> said:
when downloading files from my site, when file types are known (i.e *.doc)
browsers open the file for viewing.

is there a way to disable that and just present the save as dialog (same as
for unknown types zip files etc.)


i don't get a save dialogue with .zip files and .doc files don't open in
my browser. don't assume your visitors have their computer setup the
same way you do or want the same setup you have. if you want a "save
dialog" then change *your* preferences.
--
b r u c i e
Jul 20 '05 #4

P: n/a
Mel wrote:
when downloading files from my site, when file types are known (i.e *.doc)
browsers open the file for viewing.

is there a way to disable that and just present the save as dialog (same as
for unknown types zip files etc.) ?


Ultimately, this decision of whether to open automatically, or save
should be up to the user, which is why most user agents I know of
generally present this choice to the user, with an option to set a
default choice.

You could use the Content-disposition header, or send the file as
application/octet-stream, rather than correctly as application/msword,
but both these options may cause unexpected behaviour if the user had
chosen to automatically open word documents.

Also, if you choose to send it as application/octet-stream, you
should be aware that some corporate servers block that mime type from
being downloaded through their network because it can be used for .exe
files, containing viruses, so some users may not be able to access your
file if you did that.

Instead, you should simply inform the user that it is a word
document, and let them decide for themselves, rather than trying to make
the decision for them.

--
Lachlan Hunt
http://www.lachy.id.au/
Jul 20 '05 #5

P: n/a
"Lachlan Hunt" <la**********@iinet.net.au> a écrit dans le message de
news:eN*****************@news-server.bigpond.net.au
is there a way to disable that and just present the save as dialog
(same as for unknown types zip files etc.) ?


Ultimately, this decision of whether to open automatically, or save
should be up to the user


You can also print 2 links, one "open" an another one "download"

Jul 20 '05 #6

P: n/a
On Wed, 26 May 2004, Pierre Goiffon wrote:
You can also print 2 links, one "open" an another one "download"


Neither of which can be remotely guaranteed to do what they claim.

The old WDG FAQ has been saying this for years. It's no less true now
than it was when it was written.
Jul 20 '05 #7

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> a écrit dans le message de
news:Pi*******************************@ppepc56.ph. gla.ac.uk
You can also print 2 links, one "open" an another one "download"


Neither of which can be remotely guaranteed to do what they claim.


I totally agree for the "open" one - depends of course on the client
configuration, so it's random.

But I'd like to ask you more precisions about the reasons why a "download"
link won't do what it is meant to ? Are you aware of problems with the MIME
headers technique on some browsers ? I thought it could be used on the main
graphical browsers : Opera, Mozilla, Netscape, IE (yes, I know there is a
lots of bugs with mime headers in IE - for ewemple Q279667)

Jul 20 '05 #8

P: n/a
On Thu, 27 May 2004, Pierre Goiffon wrote:
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> a écrit dans le message de
news:Pi*******************************@ppepc56.ph. gla.ac.uk
You can also print 2 links, one "open" an another one "download"
Neither of which can be remotely guaranteed to do what they claim.


I totally agree for the "open" one - depends of course on the client
configuration, so it's random.

But I'd like to ask you more precisions about the reasons why a "download"
link won't do what it is meant to ?


If you want a specific answer, then perhaps you would want to say just
what the properties of your download link would be? You will want to
set some MIME type, I presume - which one did you have in mind? - and
I guess you wanted also to send a content-disposition header, yes?

In your earlier answer, you cited
http://support.microsoft.com/?id=260519

I hope you're aware that this refers specifically to MSIE, which is
known to violate certain mandatory rules of RFC2616. Thus, anyone
reading the MS documentation should be aware that what they are
telling authors there, may or may not be true of a WWW-conforming
client agent.

Anyway, MS says to authors:

| You can use the content-disposition header to override this default
| behavior.

I'm sceptical that a document author can be quite so certain that they
are able to "override" a browser behaviour. Well, if MS allow them to
do it this month, the virus writers will surely take advantage of it
next month, and MS will be forced to change it again in the following
month. (IMHO it would be so much easier if they just conformed to the
published interworking specifications.)
Are you aware of problems with the MIME
headers technique on some browsers ?
Not for authors who have read the specifications and therefore
understand - as Lachlan Hunt correctly said earlier on this thread -
that the final choice of what to do, is the privilege of the recipient
and not of the sender.

Some browsers take notice of the warning in RFC2616 section 15.5, and
either disregard Content-disposition headers entirely, or use them
only as a suggestion when asking the user how to dispose the item.
I thought it could be used on the main
graphical browsers : Opera, Mozilla, Netscape,
As author you can propose it, and the browser by default will normally
do that (I think there are some issues with plug-ins, as opposed to
helper applications). But in the final analysis it is the recipient's
decision, and many browsers can have their preferences changed to
reflect that.
IE (yes, I know there is a lots of bugs with mime headers in IE
Of which the worst "bugs" are intended as "features". MS have
documented in detail the ways in which they violate the Internet
interworking requirements (but without saying, in so many words, that
these are violations).
- for ewemple Q279667)


Oh yes, there bugs too, but at least there is some hope of those being
fixed. There seems little hope of the interworking violations being
fixed.

all the best
Jul 20 '05 #9

P: n/a
Alan J. Flavell wrote:
But I'd like to ask you more precisions about the reasons why a
"download" link won't do what it is meant to ?


If you want a specific answer, then perhaps you would want to say just
what the properties of your download link would be?


Sorry to have asked with so few details. Yes, I was thinking of MIME
headers, especially the 2 well known techniques of the
application/octet-stream type and also the content-diposition: attachment.

In fact I used both of these techniques years ago in some applications that
were used in a intranet or extranet context (not for internet end users, the
reason why I asked you precisions). As far as I can remember, the
content-disposition technique was a pretty good solution for MSIE (except
some 5 version), Netscape 4, 6 and 7, Mozilla of course. And I also read it
works fine in Opera. Er, if I remember wrong don't hesitate to correct me !

You're perfectly right to say that the user is always the last one to decide
what he wants to do with a link - but in fact, you can at least notice the
main browsers default behavior and know it won't work until the user change
that behabvior.

To refresh what I remember (since that long time I'm not sure now :D) I went
to read the RFC1806 about the content-disposition header, and I saw in the
rfc 2616 15.5 section you mentionned it was updated by RFC 2183. So I get
this one, and read it. Apart from normal security considerations, I didn't
find anything that may indicates content-disposition: attachment can't be
used ?

--
Pour me répondre par mail privé, merci de supprimer _NOSPAM_ de mon
adresse.

Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/oe-quotefix/

Jul 20 '05 #10

P: n/a
Tim
On Thu, 27 May 2004 22:03:07 +0200,
"Pierre Goiffon" <pg******@free.invalid> posted:
Yes, I was thinking of MIME headers, especially the 2 well known
techniques of the application/octet-stream type and also the
content-diposition: attachment.


"application/octet-stream" merely means that the file is probably some
unidentified type of binary file (in the sense that you can't always trust
the information, so it's "probably" binary). Browsers can make of that as
they will, as there's no specific way that something like that *should*
*always* be handled, other than get the data without further manipulation
(like how some browsers can translate characters in text documents).

The logical (to me) thing to do would be download it and assess it with
whatever you use outside of your browser to handle files on your system.
MSIE is probably quite likely to have a quick look at it and probably show
it in the browser if it thought it could. e.g. Hoping that someone might
download a JPEG sent that way, rather than view it, probably isn't going to
work as you'd hope.

"content-diposition: attachment" would be unknown by some of my browsers,
and probably ignored (by them).

Yes, I can see the value of a website being able to prompt the browser that
the following link is intended to be saved rather than viewed, though I see
that more of value as mere information rather than absolute instruction.

e.g. You'd follow a link, your browser would prompt you that the site
suggests you save the data to disk. Ultimately, you decide. Though
without that extra hint, the browser would do what it normally did.

One of my browsers was rather good for that. You could right click on any
link, and as well as the usual open/save, you had treat as specific MIME
types (user definable). That meant you could send some JPEG to a picture
viewer or view this badly described file in the browser because it really
was a JPEG, text to a text viewer or in the browser, and so on...

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.
Jul 20 '05 #11

P: n/a
On Fri, 28 May 2004, Tim wrote:
On Thu, 27 May 2004 22:03:07 +0200,
"Pierre Goiffon" <pg******@free.invalid> posted:
Yes, I was thinking of MIME headers, especially the 2 well known
techniques of the application/octet-stream type and also the
content-diposition: attachment.
"application/octet-stream" merely means that the file is probably some
unidentified type of binary file (in the sense that you can't always trust
the information, so it's "probably" binary).


Let's first just discuss this content-type, without reference to any
possible content-disposition headers.

What you say is correct (and for this specific content-type, I don't
find anything in the RFC which would rule the behaviour of MSIE to be
wrong). application/octet-stream is arguably the *only* MIME
content-type which could legally be interpreted as "client is allowed
to guess", since this unique MIME type says, in effect: "this is some
bag of arbitrary bytes". The RFC (2616) doesn't even try to enforce a
rule that the only appropriate behaviour would be to save these bytes
to a file, leaving (AFAICS) the client free to make a guess if it
wants to.

All other content-types (even made-up ones) "mean" something: this one
"means" practically nothing.

MS (as described in their notorious "moniker" writeup) take this as an
excuse to inspect the actual data, take a decision about what it is,
and then take whatever action they deem fit for this particular kind
of content - in many cases without even consulting with the user.
Which means you certainly *cannot* rely on MSIE to respond to
application/octet-stream (in and of itself) by proposing a
save-to-file.

Which is probably why servers have been seen advertising a
content-type of application/ms-download in order to circumvent the IE
"moniker" mechanisms. This content-type is not amongst the types
included in the "moniker" hit-list, and the resulting behaviour of IE
is then RFC-conforming. WWW-conforming browsers could also be
expected (at least by default) to handle this content-type in the same
way.

[Of course there's nothing magical in the specific value
"application/ms-download" (which arguably ought to be
"application/vnd.ms-download" or "application/x-ms-download", since
it appears to be vendor-specific and is not registered in the IANA
list of registered MIME content types). But that's a side-issue.]
Browsers can make of that as they will, as there's no specific way
that something like that *should* *always* be handled, other than
get the data without further manipulation
Right
(like how some browsers can translate characters in text documents).
Good point - and one that all too often gets overlooked.
The logical (to me) thing to do would be download it and assess it with
whatever you use outside of your browser to handle files on your system.
Indeed
MSIE is probably quite likely to have a quick look at it and
probably show it in the browser if it thought it could. e.g. Hoping
that someone might download a JPEG sent that way, rather than view
it, probably isn't going to work as you'd hope.
That's right. Even if you call the file sample.html, and send it out
with a content-type of text/plain (to take some deliberately perverse
examples), MSIE will look inside the data and unilaterally conclude
that it's really a JPEG, and will do whatever it thinks is appropriate
for JPEGs, irrespective of what the user wanted done with text/plain.
But on the other hand if you send it as, let's say, x-foo/x-bar (which
is not on their moniker hitlist), then their documentation says that
the "moniker" mechanism will not operate; and this indeed was what I
found.
"content-diposition: attachment" would be unknown by some of my
browsers, and probably ignored (by them).


If you google for "content-disposition" with "security", you'll get a
large number of hits! And for good reason.

[other good points snipped, as I can only agree with them...]

I think the summary is:

* content-disposition can cause quite a few recent popular browsers
to propose a save-to-file, which is what Pierre was saying,

* some browsers did not implement content-disposition, maybe because
of the warnings about its security implications

* The original principle of the WWW was that servers were supposed to
advertise resources *honestly* as to their MIME type, and leave the
client to do whatever -it- had been designed or configured to do with
that MIME type, -not- to try to second-guess what the user will want
to do with the item.

* Nowadays, many resource providers consider that their users are too
stupid to know what to do with the items, so they send artificial
content-types in the hope that they will produce the right effect at
the client. However, in the final analysis such behaviour is
uncertain.
Thus, ISTM that it would be unwise to offer two different links with
different content types under the claim that the one -will- display
the contents while the other -will- download them to file. This claim
will often turn out to be true, yes, but there will be cases when it
won't, and the discrepancy with the original intentions of the WWW
will be irritating to well-informed users (and maybe confusing to the
less well-informed).

IMHO and YMMV and so on.

all the best
Jul 20 '05 #12

P: n/a
Alan J. Flavell wrote:
If you google for "content-disposition" with "security",
I just did...
you'll get a large number of hits


Indeed. But I can't say I understand it all. And I've long been
curious how MS' moniker hit-list presents a security hazard. I read
your page on mime types, but you only briefly mention security
hazards. Have you time to kill to provide an example?

BTW, you likely already know this, but in case not, I came across this
priceless phrase from MS' documentation of their type sniffer:

"If the 'suggested' (server-provided) MIME type...." Suggested?!

--
Brian

Jul 20 '05 #13

P: n/a
in post: <news:40********@news-1.oit.umass.edu>
Brian <us*****@julietremblay.com.invalid> said:
If you google for "content-disposition" with "security",
you only briefly mention security
hazards. Have you time to kill to provide an example?


[...] For example, if an executable (.exe) file is embedded with MIME
headers that misrepresent it as a JPEG image file (.jpg), Internet
Explorer will treat the file as a JPEG when evaluating whether it is
safe to open. Once this evaluation is complete, the file will be opened
according to its .exe file extension and will be executed on the local
system.
http://www.cert.org/advisories/CA-2001-36.html

although its several years old IME very few systems have the fix
applied.
--
b r u c i e
Jul 20 '05 #14

P: n/a
brucie wrote:
[...] For example, if an executable (.exe) file is embedded with MIME
headers that misrepresent it as a JPEG image file (.jpg), Internet
Explorer will treat the file as a JPEG when evaluating whether it is
safe to open. Once this evaluation is complete, the file will be opened
according to its .exe file extension and will be executed on the local
system.
http://www.cert.org/advisories/CA-2001-36.html


I'll have to assume that they know something I'm missing. But the
extract you quoted describes behavior very different to what we've
been discussing. MS/Win treats the mime-type header as merely a
"suggestion." If the mime-type it receives is known or "vague," MS
examines the content for its "true" content type. In the example
above, MS should ignore the image, scan the contents, reveal that it
is an executable or perhaps report that the type is unknown, and
present the user with a "save" dialog.

Let's say that a malicious website goes a step further, and hides an
exe as an image by making the content *look* like an image to MS,
while actually being an exe that will erase files. MS will look at the
content, decide that the content is an image, and attempt to show it
inline. Since the file is not an image, it will either be garbled, or
a broken image will appear.

I just don't see the security issue. Note that I'm not excusing MS'
behavior. I'm merely confused.

--
Brian (remove ".invalid" to email me)

Jul 20 '05 #15

P: n/a
On Sat, 29 May 2004, Brian wrote:
brucie wrote:
[...] For example, if an executable (.exe) file is embedded with MIME
headers that misrepresent it as a JPEG image file (.jpg), Internet
Explorer will treat the file as a JPEG when evaluating whether it is
safe to open. Once this evaluation is complete, the file will be opened
according to its .exe file extension and will be executed on the local
system.
http://www.cert.org/advisories/CA-2001-36.html
I'll have to assume that they know something I'm missing.


It's a bug, over and above the documented misbehaviour ("moniker"
processing) that we've been discussing.
But the extract you quoted describes behavior very different to what
we've been discussing.


Correct.

But the CERT advisory, and the MS article which it cites (now moved to
http://www.microsoft.com/technet/sec.../MS01-058.mspx )
makes it clear that the vulnerability is/was very real. AFAIK those
who keep their systems up to date with windowsupdate will be protected
against this particular bug. Those who don't (and who use IE for
general web browsing, including untrusted sites) are likely to fall
foul of one or other of quite a number of security-relevant bugs,
sooner or later.

good luck
Jul 20 '05 #16

P: n/a
On Sat, 29 May 2004, Brian wrote:
Indeed. But I can't say I understand it all. And I've long been
curious how MS' moniker hit-list presents a security hazard. I read
your page on mime types, but you only briefly mention security
hazards. Have you time to kill to provide an example?


Here's one particular scenario that I was involved in, for example.

Suppose one tries to set up a security gateway, which is meant to
protect the browser from potentially harmful content coming from
untrusted/malicious sites.

According to the RFC requirements, if the HTTP sender says the
content-type is text/plain, then it's sure to be harmless, right?
RFC2046 says:

Plain text is intended to be displayed "as-is", that is, no
interpretation of embedded formatting commands, font attribute
specifications, processing instructions, interpretation directives,
or content markup should be necessary for proper display.

So the security gateway can pass this on in the confident expectation
that no client will be so stupid as to try to interpret it as any kind
of executable code. MSIE says "Wrong!".

Similarly for what should be other harmless content-types.

Basically, then, what this security gateway needs to do is to
second-guess *ALL* of the guesses which MSIE is going to make,
and try to compensate for them. But those guesses are a moving
target: they're only documented in quite general terms. To even
begin to write an algorithm for all the bungles that it's going to
make is really beyond all reason: you'd have to analyze the content
of every HTTP content body in dozens of different ways to find out
whether it might conceivably be interpreted as a uuencoded file, as
various kinds of encoded executable - and now you even have to check
it for being a ZIP archive which might conceal hostile content...

That "security gateway" scenario is by no means the whole story, but
I think it illustrates the kind of problem.

RFC2616 makes the server-provided content-type authoritative for good
reason. I'm not saying that a browser couldn't offer some kind of
error-handling mechanism for the situation where an ineptly-configured
server is sending out the wrong content-type, but it ought to be
offered to the user with a BIG and convincing warning alert, and a
clear opportunity to abandon the attempt if they don't have reason to
trust the particular server. Certainly no browser should *ever* take
such a decision on its own authority without consulting the user
(Opera, are you listening?).

When I say "convincing warning", I don't mean the kind of anodyne
message that comes out of IE saying "scripts are usually safe [OK]":
how many naive IE users are able to translate that message into its
real meaning: "scripts will occasionally be very dangerous, and can
trash your system, install premium-rate diallers, and all kinds of
other nasty stuff, are you sure that it's worth taking that risk for
the sake of some untrusted web page?".
Jul 20 '05 #17

P: n/a
Lachlan Hunt <la**********@iinet.net.au> wrote:
Also, if you choose to send it as application/octet-stream, you
should be aware that some corporate servers block that mime type from
being downloaded through their network


Another problem with such a choice is that it may prevent search engines
from processing the data. As we know, Google now indexes e.g. Word files
and PDF files (though often poorly). What I don't know is how Google
decides which files it indexes, but it would be _logical_ for a search
engine to work by the protocol and use the Content-Type header to decide
what it will try to process.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #18

P: n/a
Alan J. Flavell wrote:
Here's one particular scenario that I was involved in, for example.

[snip]

Thanks, that clears things up.

--
Brian (remove ".invalid" to email me)

Jul 20 '05 #19

P: n/a
Brian wrote:
[snip]
MS/Win treats the mime-type header as merely a "suggestion."

[snip]

Not any more! Microsoft Windows XP Service Pack 2 fixes this behaviour:

"Q: Does your Web site contain files with file types that do not match their
Content-Type and/or file extension?

A: You should correct all of these mismatches. Both the Content-Type and the
file extension must match the type of the file for a download prompt to
appear. Be sure this is true for your Web pages as well. If the
Content-Type is plain/text, then they will not render as HTML."

<URL:http://msdn.microsoft.com/asp.net/using/understanding/security/default.aspx?pull=/library/en-us/dnwxp/html/xpsp2websites.asp#xpsp2webs_topic4>

It sounds like they've at least partially fixed this issue, although the
talk of file extensions suggests that they haven't fixed it completely.

--
Jim Dabell

Jul 20 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.