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

[Jon Bell]

In article <9e*************************@posting.google.com> ,
tony melnyk <to**@melnyk.freeserve.co.uk> wrote:

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

Simply create links to the files:

<a href="foo.zip">Download foo.zip</a>.

--
Jon Bell <jt*******@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA

[Jukka K. Korpela]

to**@melnyk.freeserve.co.uk (tony melnyk) wrote:

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.
Those are not file types in the Internet context. On the Internet, the
type of a file is indicated by its "Internet media type", such as
application/msword, image/jpeg, or video/mpeg.
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?
You need to provide links to the files, and you should check that the
server sends a correct Content-Type header.
Obviously they can right click on an image and download it that way
but what about zipped files?

You can link to zipped files (application/zip) too. Some people have
software that can handle them. Beware that far from "forcing a
download", zipping makes it (namely direct download of the original,
real file format) _impossible_.

Actually you would have got this information faster by checking the
FAQ, specifically
http://www.htmlhelp.com/faq/html/med...download-howto

Well, admittedly the FAQ is a bit dusty now, and contains even
questionable advice regarding application/octet-stream.

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

[Neal]

On Sat, 7 Feb 2004 07:18:05 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:

You can link to zipped files (application/zip) too. Some people have
software that can handle them.

Some?

I would think a better word would be "many", but that's not based on
anything empirical.

[Jukka K. Korpela]

Neal <ne*****@spamrcn.com> wrote:

You can link to zipped files (application/zip) too. Some people have
software that can handle them.

Some?

I would think a better word would be "many", but that's not based on
anything empirical.

Undoubtedly "many" would be objectively correct too. But I think "some"
is a better one in this context, since the point is that only some
people have such software. Actually, many people are still using e.g.
old Windows systems that do not contain any unzipping program unless
such a program has specifically been installed. (Besides, even if there
is such a program in the user's system, there's no guarantee that he
can use it.)

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

[Neal]

On Sun, 8 Feb 2004 00:15:04 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:

Neal <ne*****@spamrcn.com> wrote:

You can link to zipped files (application/zip) too. Some people have
software that can handle them.

Some?

I would think a better word would be "many", but that's not based on
anything empirical.

Undoubtedly "many" would be objectively correct too. But I think "some"
is a better one in this context, since the point is that only some
people have such software. Actually, many people are still using e.g.
old Windows systems that do not contain any unzipping program unless
such a program has specifically been installed. (Besides, even if there
is such a program in the user's system, there's no guarantee that he
can use it.)

So I'd think it would be wise to provide a link to a free unzipper program
if you're offering zips. In fact, there are probably free Word file
viewers which you could link to as well.

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

[Brian]

Neal wrote:

there are probably free Word file viewers which you could link to
as well.
I'd be surprised if such a thing existed.
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.

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

[Sherm Pendley]

Brian wrote:

Neal wrote:

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

I'd be surprised if such a thing existed.

Surprise:

<http://office.microsoft.com/downloads/2000/wd97vwr32.aspx>

sherm--

[Brian]

Sherm Pendley wrote:

Brian wrote:

Neal wrote:

there are probably free Word file viewers

I'd be surprised if such a thing existed.

Surprise:
<http://office.microsoft.com/downloads/2000/wd97vwr32.aspx>

:-)

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

[Jukka K. Korpela]

Neal <ne*****@spamrcn.com> wrote:

So I'd think it would be wise to provide a link to a free unzipper
program if you're offering zips.
Not really. For example, if someone is using WinXP, he should probably
learn to understand the built-in unzipper rather than look for
something new.

If you offer zips as alternatives to HTML format, just offer them. If
you like, add a link to a page that explains what zip is about, in
layman terms, if you know one.

If you offer zips as the only alternative, a large number of users will
just go elsewhere.
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?
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? Surely there are
lots of applications that could be used to enhance pages, but I don't
think we are talking about interactive animations and things like that
here. PDF and Word are just proprietary and inflexible formats for
things that can mostly be better expressed in HTML, for the purposes of
WWW authoring.

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

[Neal]

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

Neal <ne*****@spamrcn.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*****@julietremblay.com.invalid-remove-this-part> wrote in
news:mHrVb.205455$nt4.975966@attbi_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*****@julietremblay.com.invalid-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 interoperability 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.