Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Arno Welzel <usenet@arnowelzel.de>
Newsgroups: comp.lang.php
Subject: Re: Generating "download" pages
Date: Sun, 20 Jul 2014 01:04:33 +0200
Lines: 45
Message-ID: <53CAF981.809@arnowelzel.de>
References: <6H9yv.30802$el1.16727@fx26.iad> <6732922.VsfUzaneRC@PointedEars.de> <lqeamt$jjv$1@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net YsSvwYUuYzavqBVlNPbmLAdRTU9ZEKeBodN4zYh4x5RuS2jg4Q
Cancel-Lock: sha1:PcmxGWTb8awGN6g7IXm1smCY5DI=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <lqeamt$jjv$1@solani.org>
X-Enigmail-Version: 1.6
Xref: csiph.com comp.lang.php:14134

Christoph M. Becker, 2014-07-19 19:43:

> Thomas 'PointedEars' Lahn wrote:
> 
>>> On response to a trigger on one web page, I want to be able to generate
>>> and display a new web page, /and/ at the same time, send an associated
>>> file as a download.
>>>  
>>> How do I do this with PHP?
>>
>> There are several ways.  Another is:
>>
>>   <?php
>>     header('Content-Disposition: attachment; filename="foo.bar"'); …
>>     header('Location: http://download.example/foo.bar');
>>   ?>
>>
>>   displayed content
> 
> How is that supposed to work?  HTTP can only deliver a single response,
> and AFAIK there is no such thing as multipart responses for HTTP.

It will not work - the browser will likely follow the Location header
and just ignore the Content-Disposition.

> Using a Refresh header instead of Location might work, but on one hand
> the Refresh is not part of the HTTP/1.1 specification (CMIIW), and on
> the other the effect is not exactly what the OP asked for.  It seems to
> me the only way to get this behavior would be in combination with client
> side scripting, what would be on-topic for comp.lang.javascript, for
> instance.

Yep - it's right, a Refresh header is not part of HTTP/1.1 - but most
browsers will still accept it (at least when using <meta
http-equiv="refresh" ...>) and behave as expected. As a fall back one
should offer a direct link within the displayed content anyway - since
client side scripting may also not work if the user did not enable it.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de