opening a client application from a server?

[ccc31807]

PROBLEM SOLVED!

What a dunce am I! All I had to do was link to the directory rather
than the document. Not only will this enable the end user to open the
document in the native application on the client machine, but it also
has the very beneficial side effect of avoiding the creation of links
to all the documents. This works in IE, FF, Opera, and Safari.

As soon as I got to work this morning, I realized that I was following
my client's instructions too literally. The fix took literally about
six seconds, and my client was very happy.

Apologies to those who were misled by my confusion.

As an end note, I'm happy with the way OOXML has worked out. I can now
create Word documents, and presumably Excel workbooks and PowerPoint
presentations, by writing XML files. I view this as a great leap
forward, and report that Perl is just as capable now of creating
Office documents as it is ordinary text files, and thus lives up to
its name as a practical extraction and reporting language.

Thanks to everyone who responded, and again, please accept my apology
for my initial confusion.

CC.

 

[Peter J. Holzer]

I think it is an Apache problem, but we don't have enough information to
be sure.

This is what I can't understand. I import a big glob of data from a
database into my script, generate many csv files, or txt files, or pdf
files, or xml file, etc., and generate links. The browsers, IE but FF
as well will happily open a csv file in Excel (assuming that the
client is a Windows machine with Office installed), open a pdf file in
Acrobat, open a txt file in the browser window, and so on.

This is because the server (Apache in your case) is configured to send
the correct content-type for these file types *and* because the browser
is configured to invoke the appropriate application for each of these
content-types. You may not personally have configured the server or the
browser, but if you look at their configuration you will see it.

I ASSUMED(!) that a doc file would work the same way, that is, open
natively in Word on a machine running Office. It doesn't, and I don't
know enough to understand why it doesn't.

There are two possibilities:

* The server is not configured to recognize MS-Word files and send an
appropriate content-type (e.g., application/msword).
* The browser is not configured to invoke MS-Word for documents of type
application/msword.

I think it probably is the former: Apache uses the extension to
determine the file type (because that's a lot faster than actually
looking into the file) and .doc has been historically used for many
different file formats, so that it's probably too dangerous to assume
that any file ending with ".doc" is a Word document.

But that's easy to check: Just retrieve the file with wget, and it will
tell you the content-type. If it's Apache, fix the Apache config. If
it's the browser, fix the browser config.

I didn't. When I produce csv, pdf, etc., I don't specify any Content-
Type.

Oh, yes, you do. You create files with a specific extension (e.g.,
".pdf") and you (or whoever configured the server) set up a config file
which maps the extension ".pdf" to the content-type "application/pdf".

I just create the files and they open the way they should. XML
is very picky, and Word demands a PERFECT(!) XML file to open,
otherwise it throws an error, and I suspect that an attempt to
incorporate a Content-Type element in the XML would create a problem.

The content type doesn't belong into the XML file. It needs to be sent
in the HTTP header.

Besides, I don't understand why a Content-Type is necessary.

A content type is always necessary. It is a mandatory part of the HTTP
protocol. You were just lucky that Apache was already set up in a way
to choose the correct content type for the files you generated.

hp

 

[Jürgen Exner]

I think it is an Apache problem, but we don't have enough information to
be sure.

Yes, it was either or. Either Apache wasn't configured to create the
correct content type in the HTTP header or the OP didn't set the correct
content in the HTTP header.

As we established in a different branch of this thread everyone assumed
the later because he was talking about CGI while the OP was actually
talking about the former.

jue