Downloading files

[tony melnyk]

I'm currently constructing a site one page of which I wish to allow
the user to select from a number of different file type downloads. The
file types will be .docs .jpgs mp3.
I know how to transfer the files to the server but what code do I need
to use to allow user to select and download specific files? Obviously
they can right click on an image and download it that way but what
about zipped files?

Regards Tony

[Neal]

On Sun, 8 Feb 2004 21:41:15 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tu t.fi> wrote:

Neal <ne*****@spamrc n.com> wrote:

In fact, there are probably free
Word file viewers which you could link to as well.

Even more pointless. Who's going to download tens of megabytes of
OpenOffice just to view a document that could be loaded and shown in no
time if it were in HTML?

I agree - was just for the sake of argument.

Interesting - what files do we feel a user should be expected to be
able to handle? Clearly html, jpg, gif. Others?

All user agents can handle those, properly served, or present the
author-supplied fallback (the alt attribute) for images. They can also
deal with text/plain (mostly). What else do you need?

I don't, but someone might think they do. When they find this archived
somewhere in the future, they'll know then.

[Eric Bohlman]

Brian <us*****@juliet remblay.com.inv alid-remove-this-part> wrote in
news:mHrVb.2054 55$nt4.975966@a ttbi_s51:

Neal wrote:

what files do we feel a user should be expected to be able to
handle? Clearly html, jpg, gif. Others?

I assume text/html and text/plain. I don't assume too much beyond that.

image/png is pretty safe as long as you don't rely on alpha channel
support. audio/mpg (or should that be audio/mpeg) is also pretty safe as
long as you just link to it rather than embed it.

[Brian]

Eric Bohlman wrote:

Brian wrote

Neal wrote:

what files do we feel a user should be expected to be able to
handle? Clearly html, jpg, gif. Others?
text/html and text/plain. I don't assume too much beyond that.

image/png is pretty safe as long as you don't rely on alpha channel
support.

As J. Korpela pointed out, images formats are appropriate if
appropriate fallback is available. That is a general principle.
audio/mpg (or should that be audio/mpeg) is also pretty
safe as long as you just link to it rather than embed it.

Anything is safe if you link to it. But I don't *assume* the user will
have what is necessary to access it, outside of the two I mentioned
above.

--
Brian (follow directions in my address to email me)
http://www.tsmchughs.com/

[Tim]

Neal wrote:

what files do we feel a user should be expected to be able to
handle? Clearly html, jpg, gif. Others?

Brian <us*****@juliet remblay.com.inv alid-remove-this-part> wrote:
I assume text/html and text/plain. I don't assume too much beyond that.

Even plain text isn't platform generic:

The end-of-line characters being the common pitfall (different systems
use different ones, and handle alternative system's methods with varying
degrees of success).

The character set being another. Trying to view a Mac written plain
text file on another computer often ends up with some gibberish
characters.

And some people's ideas about what's a plain text file are quite wrong.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

On Mon, 9 Feb 2004, Tim wrote:

Even plain text isn't platform generic:

The end-of-line characters being the common pitfall (different systems
use different ones, and handle alternative system's methods with varying
degrees of success).
Fair comment
The character set being another. Trying to view a Mac written plain
text file on another computer often ends up with some gibberish
characters.
Not really, at least with HTTP: that's no different for text/plain
than it is for text/html, so long as the server is doing what it
should and supplying the correct character encoding value on the
charset= attribute of the Content-type header.

(Quite a number of present-day non-Mac-platform browsers support Mac
encodings, for text/html as for text/plain, even though I'd rate the
use of proprietary Mac encodings for interworking as being at least as
rude as using some Other Vendor's proprietary encodings in such a
situation.)
And some people's ideas about what's a plain text file are quite wrong.

There's an RFC that defines it. I give you
http://www.cis.ohio-state.edu/cgi-bi...html#sec-4.1.3

Sure, there's a major vendor who sees fit to disregard the RFCs
whenever it suits them, but until they manage to fool enough of the
great unwashed into preferring their proprietary network instead of
the open-protocol Internet (and we can see they're working hard at
that, let's just hope that the public wake up before it's too late),
the RFCs are the right way to go.

[Tim]

Tim wrote:

Even plain text isn't platform generic:

...[snip]...

The character set being another. Trying to view a Mac written plain
text file on another computer often ends up with some gibberish
characters.

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote:

Not really, at least with HTTP: that's no different for text/plain
than it is for text/html, so long as the server is doing what it
should and supplying the correct character encoding value on the
charset= attribute of the Content-type header.
That was my main concern: Often, the user won't have control over that,
or doesn't know about it, or know what to do with it.
(Quite a number of present-day non-Mac-platform browsers support Mac
encodings, for text/html as for text/plain, even though I'd rate the
use of proprietary Mac encodings for interworking as being at least as
rude as using some Other Vendor's proprietary encodings in such a
situation.) And some people's ideas about what's a plain text file are quite wrong.

There's an RFC that defines it. I give you
http://www.cis.ohio-state.edu/cgi-bi...html#sec-4.1.3
I was thinking more of a user issue, though: Some people think that if
they use WordPad without playing with fonts and things, or SimpleText,
and just save the file "as-is," that they're making a plain text
document. Likewise for those who think that renaming a .doc file to a
..txt file converts it. It's not obvious, to them, that they've created
something that's not plain text.
the RFCs are the right way to go.

No argument from me. Doing things to a standard is the only way to
achieve interoperabilit y and maintainability .

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

This message was sent without a virus, please delete some files yourself.