Help: Make a php file return a zip file?

[nicholas4]

I need help with writing a script that returns a zip file.

if(1 == $download){
// Setup headers for zip file
// Return zip file
// Afterwards, display previous php page
}

Can you help with fleshing out the function. I think I have the basic
idea of what needs to be done, but I don't know what the syntax is.

Thanks!

[Ehtor]

ni*******@gmail.com wrote in
news:11*********************@f14g2000cwb.googlegro ups.com:

I need help with writing a script that returns a zip file.

if(1 == $download){
// Setup headers for zip file
// Return zip file
// Afterwards, display previous php page
}

Can you help with fleshing out the function. I think I have the basic
idea of what needs to be done, but I don't know what the syntax is.

Thanks!

Not sure I understand the flow you're trying to achieve, but I'll try and
help a little. Let's assume you have a generic link on a web page and when
the user clicks the link you want to shoot them an arbitrary zip file (ie,
a zip file determined NOT by the link itself, but by the script the link
calls.)

<A HREF="shootzip.php">Click here for file</A>

Now, shootzip.php looks something like this:

<?

$zipfile = <name of zip file you want to send>;
$theirfile = <name of zip file you want the prompt box to default to on the
user side>;'

header("Content-Disposition: attachment; filename=\"$theirfile\"");
header("Content-type: application/octet-stream; name=$theirfile");

readfile( $zipfile );

?>
This will *not* open a new window and the user will stay on the page w/ the
link. You could use Java script to get more fancy.

Is this kinda what you were looking for?

[John Dunlop]

ni*******@gmail.com wrote:

I need help with writing a script that returns a zip file.

[ ... ]

Ehtor wrote:
header("Content-Disposition: attachment; filename=\"$theirfile\"");
header("Content-type: application/octet-stream; name=$theirfile");

The registered MIME type for zip files is application/zip,
the IANA's definition of which does not allow for any
parameters.

http://www.iana.org/assignments/medi...pplication/zip

The often misused octet-stream subtype indicates that the
body of the message is 'arbitrary binary data', which is
inappropriate if a subtype is registered that better
describes the data.

http://www.ietf.org/rfc/rfc2046.txt

By the way, 'name' as a parameter to octet-stream was
deprecated over eleven years ago, in favour of the C-D
header.

--
Jock

[Ehtor]

John Dunlop <us*********@john.dunlop.name> wrote in
news:MP************************@News.Individual.NE T:

ni*******@gmail.com wrote:

> I need help with writing a script that returns a zip file.

[ ... ]

Ehtor wrote:

header("Content-Disposition: attachment; filename=\"$theirfile\"");
header("Content-type: application/octet-stream; name=$theirfile");

The registered MIME type for zip files is application/zip,
the IANA's definition of which does not allow for any
parameters.

http://www.iana.org/assignments/medi...pplication/zip

The often misused octet-stream subtype indicates that the
body of the message is 'arbitrary binary data', which is
inappropriate if a subtype is registered that better
describes the data.

http://www.ietf.org/rfc/rfc2046.txt

By the way, 'name' as a parameter to octet-stream was
deprecated over eleven years ago, in favour of the C-D
header.

Yes, you're correct. A shame you didn't actually answer the poster's
original question with your wealth of knowledge.

For the original poster's question, here's the revised PHP code:

header("Content-Disposition: attachment; filename=\"$theirfile\"");
header("Content-type: application/zip");
readfile( $zipfile );
By the way, if you review email headers, you'll note that many MIME
messages still include the name parameter in the C-T header. It should
also be noted that the original solution will work to serve ANY binary data
-- including ZIP.

[John Dunlop]

Ehtor wrote:

A shame you didn't actually answer the poster's original
question
Sorry, but if you thought I was here foremost to answer
questions, then I'm afraid you were mistaken.
with your wealth of knowledge.
Hardly. The misuse of application/octet-stream is so
widespread that to recite chapter and verse on it is nothing
out of the ordinary.

[ ... ]
By the way, if you review email headers, you'll note that many MIME
messages still include the name parameter in the C-T header.
While that may be, the MIME spec says the name parameter is
deprecated; further, the previous spec, published in 1993,
also said it was deprecated. That's deprecated, not merely
discouraged. That other implementations haven't cottoned on
yet is no license for you to disregard the spec.
It should also be noted that the original solution will work to serve
ANY binary data -- including ZIP.

What reason is there to send zip files as application/octet-
stream when application/zip has been registered?

--
Jock

[Ehtor]

John Dunlop <us*********@john.dunlop.name> wrote in
news:MP************************@News.Individual.NE T:

Ehtor wrote:

A shame you didn't actually answer the poster's original
question

Sorry, but if you thought I was here foremost to answer
questions, then I'm afraid you were mistaken.

Guess so. Why are you here?

with your wealth of knowledge.

Hardly. The misuse of application/octet-stream is so
widespread that to recite chapter and verse on it is nothing
out of the ordinary.

[ ... ]

Maybe there's a reason for that...

By the way, if you review email headers, you'll note that many MIME
messages still include the name parameter in the C-T header.

While that may be, the MIME spec says the name parameter is
deprecated; further, the previous spec, published in 1993,
also said it was deprecated. That's deprecated, not merely
discouraged. That other implementations haven't cottoned on
yet is no license for you to disregard the spec.

I have no idea what "cottoned on" means... But at least you used "yet"
to imply that 12 years is not long enough...

It should also be noted that the original solution will work to serve
ANY binary data -- including ZIP.

What reason is there to send zip files as application/octet-
stream when application/zip has been registered?

How about simplicity of code when delivering varying/multiple filetypes?
Not all standards (registered or not) suit individual business needs.
Respecting the RFC's is different from hiding behind them. Now, the
orignal poster has enough info to make an informed decision that is
appropriate for their circumstance.

I agreed that you were correct in your original reply post. I agreed
that, without knowing more about what the poster was trying to do, that
MIME-zip was the spec-correct solution. My objection was to your
lecturing instead of educating style. I'm over it now.

[John Dunlop]

Ehtor wrote:

[John Dunlop wrote:]

Sorry, but if you thought I was here foremost to answer
questions, then I'm afraid you were mistaken.

Guess so. Why are you here?

First, to learn. Second, to give a little back. Neither
reason necessarily entails answering questions.

Nobull summed it up:

'Get real! *This is a discussion group not a helpdesk. You
post something we discuss its implications. If the
discussion happens to answer a question you've asked that's
incidental.'

news:u9************@wcl-l.bham.ac.uk

[ ... ]

What reason is there to send zip files as application/octet-
stream when application/zip has been registered?

How about simplicity of code when delivering varying/multiple filetypes?

I don't expect anyone to serve files using complicated code.
The file type is known in advance here, so it doesn't get
much simpler. If the file type is unknown, though, PHP can
determine it, or at least try to:

http://www.php.net/manual/en/functio...ntent-type.php
Not all standards (registered or not) suit individual business needs.
OK, a situation could arise where breaking a rule is
justified. I mean, nobody expects rigid adherence to every
single specification. (For starters, specifications
themselves sometimes contain errors.)

[ ... ]
Now, the orignal poster has enough info to make an informed decision
that is appropriate for their circumstance.

Yes, good.

--
Jock

[dougerz]

I was able to use Ethor's suggestion to fix a problem I'm having. M
original problem was that I was missing the quotes around th
filename in the CD header. I've read the ensuing dialog between Etho
and JD and have a question/comment driven by the fact that thing
don't seem to work for me the way they're "supposed to" and I wonde
why

I use a content type application/zip, and a content disposition wit
the file name (test.zip) just like JD suggests. But it only works i
the HTTP request ends with ".zip".
My request i
http://a.b.c.net/cc/production.php?file=123&zip=.zi
I get a valid zip file downloaded, but the filename isn't the filenam
in the CD header - its cc.zip

Furthermore, if I make the request
http://a.b.c.net/cc/production.php?file=123&zip
(no .zip on the end, which is what I wanted it to be), it doesn't wor
at all. The dialog box that pops up is making the filename
?file=123&zip

(Note: I'm using IE as the browser. My server is remote from where
am, and I go through all kinds of route point and a VPN to get to th
server. Also note that this works when I browse to my local machine.

I've tried various combinations of application/zip, octet-stream
lower/upper case, quotes/no quotes, order, etc. All have the sam
result described above. The only two headers I specify in PHP are th
CT and the CD

I making a SWAG that some device between my browser and the remot
server is monkeying around with the request and/or response headers
Otherwise why would the response headers that my PHP application ha
correctly applied? Is there something in the Apache or PH
configuration I need to look at
http://eye.cc -php- web design

[John Dunlop]

dougerz wrote:

My original problem was that I was missing the quotes around the
filename in the CD header.
In spite of HTTP/1.1, the quotes are not usually necessary.
If the filename is short and doesn't contain certain special
characters, then you shouldn't quote it. Quotes are
necessary only if the filename is long or contains those
special characters. The details are laid out in RFC2183, if
you're interested.

http://www.ietf.org/rfc/rfc2183.txt
I've read the ensuing dialog between Ethor and JD and have a
question/comment driven by the fact that things don't seem to work
for me the way they're "supposed to" and I wonder why.
'Supposed to' isn't quite right. Since the C-D header isn't
part of HTTP, it's quite understandable why some browsers
don't observe it. I'm sure many simply ignore it. Besides,
C-D is nothing more than an indication; it doesn't force.

Me, well, I don't think C-D is useful to the web.
I use a content type application/zip, and a content disposition with
the file name (test.zip) just like JD suggests. But it only works if
the HTTP request ends with ".zip".
[ ... ]

I wouldn't expect perfection in every implementation, much
less Internet Explorer, by no means the paragon of web
browsers! The thing to do, as a provider, is publish
material in accordance with the interworking specifications.

There is a FAQ addressing this, but I don't know how helpful
you'll find it or if it'll reveal anything new.

http://www.htmlhelp.com/faq/cgifaq.3.html#22

Also, this could soon be an entry in the comp.lang.php FAQ
(nudge, nudge, anyone willing), so stay tuned.
I making a SWAG that some device between my browser and the remote
server is monkeying around with the request and/or response headers.

You can check what the headers are with

http://www.delorie.com/web/headers.html

Slàinte!

--
Jock