Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14133

Re: Generating "download" pages

Show all headers | View raw

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>> and AFAIK there is no such thing as multipart responses for HTTP.
>> 
>> There is; that is the purpose of the “Content-Disposition” header field.
>> 
>> <http://tools.ietf.org/html/rfc6266>
> 
> Um, I am somewhat confused.  RFC 6266 says (emphasis mine):
> 
> | The Content-Disposition response header field is used to convey
> | additional information about *how to process the response payload*,
> | and also can be used to attach additional metadata, such as the
> | filename to use when *saving the response payload locally*.
> 
> This seems to be completely different then e.g. "Content-Type:
> multipart/alternative" for emails.

It is not all that different.

>> | Response Headers (source)
>> | 
>> | HTTP/1.1 302 Found
>> | Location:
>> 
http://netcologne.dl.sourceforge.net/project/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip
>> 
>> Note that the response body is displayed as empty.
> 
> This is not surprising, as the HTTP response status code is "302 Found",
> which redirects to the URI given in the Location header field.

ACK.  It would appear I was partially mistaken and you were right.  The link 
on sourceforge.net appears to be no different than any other download link, 
except that server-side redirection is used.

>> I think the relevant fact here is that the target resource is served with
>> “Content-Type: application/octet-stream”, because that is known to
>> trigger a download dialog instead of navigation.
> 
> ACK.  However, the content that could be saved, is the payload of the
> very response that contained the Content-Type header field.

Not necessarily.  Such content can be part of a multi-part message.
 
>> <http://stackoverflow.com/questions/283752/refresh-http-header>
> 
> Thanks for the confirmation.

I have created testcases:

<http://pointedears.de/scripts/php/test/download-redirect>
<http://pointedears.de/scripts/php/test/download-multipart>
<http://pointedears.de/scripts/php/test/download-refresh>

The first and third one redirect/refresh to

<http://pointedears.de/scripts/php/test/download-redirect2>

All three trigger the download dialog in Chromium 34.  However, only the 
latter also displays the HTML document at the same time, even though I 
specified a relative URI-reference.  Since the “Refresh” header field is so 
far a non-standard feature, either it should not be used or it should be 
used as an alternative to client-side scripting (as you suggested), with a 
“direct link” in case neither works (as SourceForge does).  One must decide 
for either HTTP or client-side scripting as using both might trigger the 
download two times.

“download-multipart” and “download-refresh” take parameters to use “Content-
Disposition: inline” instead of “attachment”, and to use the “meta” element 
instead of the HTTP header field, respectively.

Append “.phps” to the URIs for the source code.


I still do not understand why SourceForge would use the “Content-
Disposition” header field in their redirect as the message body truly is 
empty:

$ GET -Se 
'http://downloads.sourceforge.net/project/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fviplugin%2F&ts=1405807555&use_mirror=heanet' 
| head -n 30
GET 
http://downloads.sourceforge.net/project/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fviplugin%2F&ts=1405807555&use_mirror=heanet
302 Found
Connection: close
Date: Sat, 19 Jul 2014 22:08:02 GMT
Location: 
http://heanet.dl.sourceforge.net/project/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip
Server: lighttpd
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 19 Jul 2014 22:08:02 GMT
Client-Peer: 216.34.181.59:80
Client-Response-Num: 1
Content-Disposition: attachment; filename="viPlugin_0.2.11_E30.zip"
Set-Cookie: 
sf_mirror_attempt=viplugin:heanet:/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip; 
expires=Sat, 19-Jul-2014 22:10:02 GMT; Path=/
X-Frame-Options: SAMEORIGIN

GET 
http://heanet.dl.sourceforge.net/project/viplugin/viplugin/0.2.11/viPlugin_0.2.11_E30.zip
200 OK
Connection: close
Date: Sat, 19 Jul 2014 22:08:02 GMT
Accept-Ranges: bytes
ETag: "1011c768e-2752f-3d7fa7c386b00"
Server: Apache/2.2.14
Content-Length: 161071
Content-Type: application/octet-stream
Last-Modified: Tue, 13 Apr 2004 22:35:56 GMT
Client-Date: Sat, 19 Jul 2014 22:08:05 GMT
Client-Peer: 193.1.193.66:80
Client-Response-Num: 1

PK[zipped content]

> [Sorry, I had to snip more of the former discussion than I liked,
> because my newsserver doesn't allow too much quoted content.]

I know what you mean as I am also using this server and recommended it to 
you.  This is its major (but AFAICS only) disadvantage.  TINSTAAFL.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-18 09:55 -0400
  Re: Generating "download" pages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-18 17:39 +0200
    Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 11:38 -0400
      Re: Generating "download" pages Jerry Stuckle <jstucklex@attglobal.net> - 2014-07-19 16:57 -0400
        Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 17:06 -0400
    Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 11:58 -0400
      Re: Generating "download" pages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-19 19:06 +0200
    Re: Generating "download" pages "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-07-19 19:43 +0200
      Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 14:23 -0400
        Re: Generating "download" pages "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-07-19 22:18 +0200
          Re: Generating "download" pages "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-07-19 22:38 +0200
            Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 16:54 -0400
              Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 17:00 -0400
                Resolved: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-20 14:34 -0400
      Re: Generating "download" pages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-19 20:50 +0200
        Re: Generating "download" pages "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-07-19 22:06 +0200
          Re: Generating "download" pages Jerry Stuckle <jstucklex@attglobal.net> - 2014-07-19 16:54 -0400
          Re: Generating "download" pages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-07-20 00:48 +0200
      Re: Generating "download" pages Arno Welzel <usenet@arnowelzel.de> - 2014-07-20 01:04 +0200
  Re: Generating "download" pages Arno Welzel <usenet@arnowelzel.de> - 2014-07-19 18:17 +0200
    Re: Generating "download" pages Jerry Stuckle <jstucklex@attglobal.net> - 2014-07-19 16:55 -0400
  Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 12:25 -0400
    Re: Generating "download" pages Tim Streater <timstreater@greenbee.net> - 2014-07-19 17:36 +0100
      Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 13:53 -0400
        Re: Generating "download" pages Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-19 14:14 -0400
        Re: Generating "download" pages Curtis Dyer <dyer85@gmail.com> - 2014-07-23 00:38 +0000

csiph-web