file types & automatic openning...

[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

[Jim Dabell]

Re: file types & automatic openning...

Mel wrote:
[color=blue]
> 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.) ?[/color]

The FAQ covers this:

<URL:http://www.htmlhelp.or g/faq/html/media.html#forc e-download>

Also:

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

--
Jim Dabell

[Pierre Goiffon]

Re: file types &amp; automatic openning...

Mel wrote:[color=blue]
> 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.) ?[/color]

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/

[brucie]

Re: file types &amp; automatic openning...

in post: <news:c8vq5l$b7 m$1@s0b1a68.ssa .gov>
Mel <mehra.heravi@s sa.gov> said:
[color=blue]
> 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.)[/color]

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

[Lachlan Hunt]

Re: file types &amp; automatic openning...

Mel wrote:[color=blue]
> 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.) ?[/color]

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/

[Pierre Goiffon]

Re: file types &amp; automatic openning...

"Lachlan Hunt" <lachlan.hunt@i inet.net.au> a écrit dans le message de
news:eNTsc.1116 4$L.11149@news-server.bigpond. net.au[color=blue][color=green]
>> is there a way to disable that and just present the save as dialog
>> (same as for unknown types zip files etc.) ?[/color]
>
> Ultimately, this decision of whether to open automatically, or save
> should be up to the user[/color]

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

[Alan J. Flavell]

Re: file types &amp; automatic openning...

On Wed, 26 May 2004, Pierre Goiffon wrote:
[color=blue]
> You can also print 2 links, one "open" an another one "download"[/color]

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.

[Pierre Goiffon]

Re: file types &amp; automatic openning...

"Alan J. Flavell" <flavell@ph.gla .ac.uk> a écrit dans le message de
news:Pine.LNX.4 .53.04052623450 80.14731@ppepc5 6.ph.gla.ac.uk[color=blue][color=green]
>> You can also print 2 links, one "open" an another one "download"[/color]
>
> Neither of which can be remotely guaranteed to do what they claim.[/color]

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)

[Alan J. Flavell]

Re: file types &amp; automatic openning...

On Thu, 27 May 2004, Pierre Goiffon wrote:
[color=blue]
> "Alan J. Flavell" <flavell@ph.gla .ac.uk> a écrit dans le message de
> news:Pine.LNX.4 .53.04052623450 80.14731@ppepc5 6.ph.gla.ac.uk[color=green][color=darkred]
> >> You can also print 2 links, one "open" an another one "download"[/color]
> >
> > Neither of which can be remotely guaranteed to do what they claim.[/color]
>
> 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 ?[/color]

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. )
[color=blue]
> Are you aware of problems with the MIME
> headers technique on some browsers ?[/color]

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.
[color=blue]
> I thought it could be used on the main
> graphical browsers : Opera, Mozilla, Netscape,[/color]

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.
[color=blue]
> IE (yes, I know there is a lots of bugs with mime headers in IE[/color]

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).
[color=blue]
> - for ewemple Q279667)[/color]

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

[Pierre Goiffon]

Re: file types &amp; automatic openning...

Alan J. Flavell wrote:[color=blue][color=green]
>> But I'd like to ask you more precisions about the reasons why a
>> "download" link won't do what it is meant to ?[/color]
>
> If you want a specific answer, then perhaps you would want to say just
> what the properties of your download link would be?[/color]

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/

[Tim]

Re: file types &amp; automatic openning...

On Thu, 27 May 2004 22:03:07 +0200,
"Pierre Goiffon" <pgoiffon@free. invalid> posted:
[color=blue]
> 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.[/color]

"applicatio n/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.

[Alan J. Flavell]

Re: file types &amp; automatic openning...

On Fri, 28 May 2004, Tim wrote:
[color=blue]
> On Thu, 27 May 2004 22:03:07 +0200,
> "Pierre Goiffon" <pgoiffon@free. invalid> posted:
>[color=green]
> > 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.[/color]
>
> "applicatio n/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).[/color]

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
"applicatio n/ms-download" (which arguably ought to be
"applicatio n/vnd.ms-download" or "applicatio n/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.]
[color=blue]
> 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[/color]

Right
[color=blue]
> (like how some browsers can translate characters in text documents).[/color]

Good point - and one that all too often gets overlooked.
[color=blue]
> 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.[/color]

Indeed
[color=blue]
> 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.[/color]

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.
[color=blue]
> "content-diposition: attachment" would be unknown by some of my
> browsers, and probably ignored (by them).[/color]

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

[Brian]

Re: file types &amp; automatic openning...

Alan J. Flavell wrote:
[color=blue]
> If you google for "content-disposition" with "security",[/color]

I just did...
[color=blue]
> you'll get a large number of hits[/color]

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

[brucie]

Re: file types &amp; automatic openning...

in post: <news:40b92b9a$ 1@news-1.oit.umass.edu >
Brian <usenet3@juliet remblay.com.inv alid> said:
[color=blue][color=green]
>> If you google for "content-disposition" with "security",[/color][/color]
[color=blue]
> you only briefly mention security
> hazards. Have you time to kill to provide an example?[/color]

[...] 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

[Brian]

Re: file types &amp; automatic openning...

brucie wrote:
[color=blue]
> [...] 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[/color]

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)