Spreadsheet Download Dialog Box (IE)

[Topmind]

If the Windows Web browser (IE 5 or 6) opens an XLS file
(spreadsheet), how it handles it depends on a file association setting
within Windows. There is a setting called "confirm open after
download" in Windows Explorer under Tools, Folder Options, File Types,
XLS (in list), Advanced (button). This setting will determine if a
"Save File" dialog box pops up or not when user clicks on a
spreadsheet link. If this option is switched off, then a spreadsheet
will directly open in the browser window. We don't want this to
happen. We want the options dialog box to appear for users.

The options dialog box has "Open", "Save", and "Cancel" options, but
also allows the user to switch off this dialog in future downloads
(links to spreadsheets); but since it never appears again once off,
there is no easy way for users to set it back on.

The problem is that this option is not controllable on the server side
that we know of. It is not realistic to expect the user to go into
the Folders Options described above. We tried changing the MIME
headers to indicate binary (octet) in ColdFusion, but it did not work.
Apparently the file extension ("XLS") overrides any MIME headers.

Does anybody know of a fix or workaround that is convenient for the
users?

Thanks, -T-

[Jim Dabell]

Topmind wrote:

If the Windows Web browser (IE 5 or 6) opens an XLS file
(spreadsheet), how it handles it depends on a file association setting
within Windows. There is a setting called "confirm open after
download" in Windows Explorer under Tools, Folder Options, File Types,
XLS (in list), Advanced (button). This setting will determine if a
"Save File" dialog box pops up or not when user clicks on a
spreadsheet link. If this option is switched off, then a spreadsheet
will directly open in the browser window. We don't want this to
happen. We want the options dialog box to appear for users. [snip]

This is covered in the FAQ:

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

When thinking of posting a question to a new newsgroup, you'll often find
that your question has already been answered many times over, so try
reading the FAQ and some of the recent threads before posting. You can
usually find the FAQ by putting the newsgroup name followed by "FAQ" into
Google.

Apparently the file extension ("XLS") overrides any MIME headers.

[snip]

Sounds like typical Internet Explorer broken behaviour. Consider switching
to a browser that doesn't violate RFC 2616 (HTTP). In other words consider
switching to _any_ other browser.
--
Jim Dabell

[Topmind]

> > If the Windows Web browser (IE 5 or 6) opens an XLS file

(spreadsheet), how it handles it depends on a file association setting
within Windows. There is a setting called "confirm open after
download" in Windows Explorer under Tools, Folder Options, File Types,
XLS (in list), Advanced (button). This setting will determine if a
"Save File" dialog box pops up or not when user clicks on a
spreadsheet link. If this option is switched off, then a spreadsheet
will directly open in the browser window. We don't want this to
happen. We want the options dialog box to appear for users. [snip]

This is covered in the FAQ:

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

When thinking of posting a question to a new newsgroup, you'll often find
that your question has already been answered many times over, so try
reading the FAQ and some of the recent threads before posting.

I searched for more than an hour. How long do you recommend searching
before asking?

You can
usually find the FAQ by putting the newsgroup name followed by "FAQ" into
Google.

I will try to remember that. Usually sombody posts the related
FAQ to the newgroup itself, so that it's content should turn up in searches
also.

BTW, somebody recommended trying:

Content-Type: application/download.

or

Content-Type: application/x-msdownload

I have yet to try them.

Apparently the file extension ("XLS") overrides any MIME headers.

[snip]

Sounds like typical Internet Explorer broken behaviour. Consider switching
to a browser that doesn't violate RFC 2616 (HTTP). In other words consider
switching to _any_ other browser.

I don't make those decisions in the given large organization. Besides,
the content was already MS-specific before I came. Thus, any change
will impose a conversion cost.

-T-

[Topmind]

>

BTW, somebody recommended trying:

Content-Type: application/download.

or

Content-Type: application/x-msdownload

I have yet to try them.

Why would you "try" them? That would just tell you how the specific
browser(s) tested react to
- an undefined and hence incorrect media type, and
- a media type that is explicitly labeled as being nonstandard, i.e.
to be used only by specific agreement between interested parties.

Moreover, if you _know_ what the registered media type of the data is,
you would give disinformation if you specify an incorrect media type or
a proprietary media type. Almost the same applies to the more common
advice of using application/octet-stream, which is a standard media
type but basically mean 'some lump of binary data, I don't know what,
or cannot describe it any better'.

Are you suggesting that those settings are no different than something
random like:

application/gdfjsdfasfoobar

?

I was under the impression that those settings were something
recognized by MS browsers, even if they are not a "formal" web
standard. Hacky? Perhaps, but a guaranteed download dialog box is what
the customer wants. They don't want lectures about standards purity.

-T-

[Jukka K. Korpela]

to*****@technologist.com (Topmind) wrote:

I was under the impression that those settings were something
recognized by MS browsers, even if they are not a "formal" web
standard.
That is, they are recognized by some browsers that are known to violate
the fundamental protocols of the Web in this respect.
Hacky?
Try "worse than useless trickery". It only hurts when it "works".
Perhaps, but a guaranteed download dialog box is
what the customer wants.
Which is not what the user needs, and is surely not possible in HTML
authoring for the World Wide Web, which is, if you allow me, what we
are trying to discuss here.
They don't want lectures about standards purity.

Neither do we want pointless "advice" from anonymous sources.
But we cannot prevent you from giving it, we can just ignore it.

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

[Jukka K. Korpela]

to*****@technologist.com (Topmind) wrote:

For intranets, what many companies really want is is a "remote GUI"
protocol.

Whatever they might want, we still try to discuss HTML authoring for the
World Wide Web here. It seems that you have missed this, among other
things. Thank you for keeping your From field as a cluelessness
indicator; please do not change it unless you have something to
contribute to the topic of this group. Thank you in advance.

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

[Topmind]

>

For intranets, what many companies really want is is a "remote GUI"
protocol.
Whatever they might want, we still try to discuss HTML authoring for the
World Wide Web here.

Is there a comp.infosystems.intranets.authoring.html ?
It seems that you have missed this, among other
things. Thank you for keeping your From field as a cluelessness
indicator; please do not change it unless you have something to
contribute to the topic of this group. Thank you in advance.

You really seemed bothered by pseudonames. This is the 3rd time
you mentioned it. The first was enough to indicate your displeasure
with it. But, I disagree. Live with it.

-T-