Edit report at https://bugs.php.net/bug.php?id=69292&edit=1

 ID:                 69292
 Updated by:         c...@php.net
 Reported by:        scott at perturb dot org
 Summary:            Download links are not wget compatible
 Status:             Open
 Type:               Bug
 Package:            Website problem
 Operating System:   All
 PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

> Does wget *always* use the last component of the url for its
> filename, or can that be fixed somehow?

wget has an --output-document option[1], which should be usable in
this case.

[1] <http://www.gnu.org/software/wget/manual/wget.html#Download-Options>


Previous Comments:
------------------------------------------------------------------------
[2015-03-25 14:34:19] bj...@php.net

scott: The location of the binary is "implementation detail", which is why we 
have php in front of it to verify.

Reordering the components in the url would break boatload of scripts out there, 
so thats hardly a realistic option.

Does wget *always* use the last component of the url for its filename, or can 
that be fixed somehow?

------------------------------------------------------------------------
[2015-03-25 00:01:12] scott at perturb dot org

Looking at the code in do-download.inc, we're not doing anything before we send 
the status_header(302) and then give them the real URL. I assumed we were 
logging the hit or something like that, thus the download needed to hit PHP.

Since ALL we're doing is a redirect to the tar file, is there a reason the 
download links can't be directly to the file on the file system, and not be 
handled by PHP?

------------------------------------------------------------------------
[2015-03-24 23:48:35] scott at perturb dot org

It's more of an annoyance than a bug. I've worked around it in the past, using 
the method you describe. Or even more simply:

wget http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror -o 
/tmp/php.tar.bz2

But I *always* forget the first time, and have to repeat it with the work 
around. It would be nice if it "just worked (tm)". Someone had the idea of 
making the download links wget compatible, because of the comment in the file:

https://github.com/php/web-php/blob/master/error.php#L136

If we just re-ordered the elements in the download link, it would be wget 
compatible with minimal changes.

------------------------------------------------------------------------
[2015-03-24 23:29:30] c...@php.net

In my opinion that is not a bug, but rather something that might be
improved, if at all -- what's wrong with something like:

    FILE=php-5.3.29.tar.bz2;\
    wget http://br1.php.net/get/$FILE/from/this/mirror;\
    mv mirror $FILE

------------------------------------------------------------------------
[2015-03-24 20:33:53] scott at perturb dot org

Description:
------------
I download the PHP release .tar.bz2 files from the php.net all the time to do 
testing. 99% of the time I navigate to the download page on my local machine, 
and copy and paste the URL in to a terminal on the server I want to compile on. 
The download URLs look like this: 
http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror which I then feed to 
wget:

    $ wget http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror

    --2015-03-24 08:58:06--  
http://br1.php.net/get/php-5.3.29.tar.bz2/from/this/mirror
    Resolving br1.php.net (br1.php.net)... 187.73.33.52
    ** [snipped] **
    HTTP request sent, awaiting response... 200 OK
    Length: 11396771 (11M) [application/octet-stream]
    Saving to: ‘mirror’

    mirror                100%[========================>]  10.87M  1.22MB/s   
in 11s    

    2015-03-24 08:58:17 (1006 KB/s) - ‘mirror’ saved [11396771/11396771]

Note that the file that gets written to disk is "mirror" and not 
php-5.3.29.tar.bz2. It's a minor annoyance, but it seems really easily fixed.

Test script:
---------------
N/A

Expected result:
----------------
When I wget a URL from a server, it should have the right file name. 

Actual result:
--------------
Wget uses the part of the URL after the last "/" as the output filename. 
Arguably this is a bug in Wget, but it's also something we can easily work 
around on the php-web side.

Someone already thought of this, because there is mention of wget style 
download links in the code:

https://github.com/php/web-php/blob/master/error.php#L136

If we remap the filename in the download URL to be at the END, it should solve 
this problem.


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=69292&edit=1

-- 
PHP Webmaster List Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to